From FORRERJ@frl.orst.edu Tue Aug 01 11:58:39 1995 
Received: from amanda.bus.orst.edu (amanda.BUS.ORST.EDU [128.193.10.36]) by 
dingus.n5lyt.datarace.com (8.6.12/8.6.9) with ESMTP id LAA29049 for 
<hfsig@tapr.org>; Tue, 1 Aug 1995 11:58:34 -0500 
Received: from frl.orst.edu (FRL.ORST.EDU [128.193.226.10]) by amanda.bus.orst.edu 
(8.6.9/8.6.9) with SMTP id JAA22686 for <hfsig@tapr.org>; Tue, 1 Aug 1995 09:58:26 
-0700 
Received: from FRL/MERCURY_MAILER by frl.orst.edu (Mercury 1.11); 

Tue, 1 Aug 95 10:03:25 PST8PDT 
Received: from MERCURY_MAILER by FRL (Mercury 1.11); Tue, 1 Aug 95 10:03:21 
PST8PDT 
From: "Johan Forrer" <FORRERJ@frl.orst.edu> 
Organization: Forest Research Lab. Oregon State 
To: hfsig@tapr.org 


Date: Tue, 1 Aug 1995 10:03:18 PST8PDT 

Subject: Re: [HFSIG:505] DWAIT/DTIME/T2 KISS parameter number 
Priority: normal 

X-mailer: PMail v3.0 (R1a) 


Message-ID: <6E895C81979@frl.orst.edu> 
Hi all, 
I am not sure that everyone picked up Timo's question and request for help? 


We need to know some information on the KISS protocol: does anyone know 
what the KISS parameter (code) for T2/Dwait/Dtime is? 
Who might know? Any help will be greatly appreciated. 


Thanks in advantage. 


--Johan, KC7WW 


From k5yfw@sacdm10.kelly.af.mil Tue Aug 01 17:33:17 1995 
Received: from sacdm10.kelly.af.mil (sacdm10.kelly.af.mil [137.242.64.10]) by 
dingus.n5lyt.datarace.com (8.6.12/8.6.9) with SMTP id RAA32423 for 
<hfsig@tapr.org>; Tue, 1 Aug 1995 17:32:53 -0500 
Received: by sacdm10.kelly.af.mil (Smail3.1.29.0 #2) 

id mOsdPgj-0002AnC; Tue, 1 Aug 95 17:21 CDT 
Message-Id: <mOsdPgj-0002AnC@sacdm10.kelly.af.mil> 
Date: Tue, 1 Aug 95 17:21:25 -0500 
From: k5yfw@sacdm10.kelly.af.mil (WALT DUBOSE - K5YFW) 
Subject: Re: [HFSIG:507] Re: DWAIT/DTIME/T2 KISS parameter number 
To: hfsig@tapr.org 
X-orig-date: Tue, 1 Aug 1995 12:12:13 -0500 
X-orig-from: "Johan Forrer" <FORRERJ@fr1l.orst.edu> 
X-orig-message-ID: <6E895C81979@frl.orst.edu> 


In your message of 1 Aug 1995 at 1212 CDT, you write: 

> Hi all, 

> 

> I am not sure that everyone picked up Timo's question and request for help? 
> 


We need to know some information on the KISS protocol: does anyone know 
what the KISS parameter (code) for T2/Dwait/Dtime is? 
Who might know? Any help will be greatly appreciated. 


Thanks in advantage. 


--Johan, KC7WW 


VVVV VV VV VV 


I'm not at home now so can't get the information but Timo might try 
sending the request to nos-bbs@hydra.carleton.ca or tcp-group@ucsd.edu 


73, Walt/K5YFW 
From FORRERJ@frl.orst.edu Tue Aug 01 18:33:43 1995 
Received: from amanda.bus.orst.edu (amanda.BUS.ORST.EDU [128.193.10.36]) by 
dingus.n5lyt.datarace.com (8.6.12/8.6.9) with ESMTP id SAAQ0059 for 
<hfsig@tapr.org>; Tue, 1 Aug 1995 18:33:38 -0500 
Received: from frl.orst.edu (FRL.ORST.EDU [128.193.226.10]) by amanda.bus.orst.edu 
(8.6.9/8.6.9) with SMTP id QAA25539 for <hfsig@tapr.org>; Tue, 1 Aug 1995 16:33:29 
-0700 
Received: from FRL/MERCURY_MAILER by frl.orst.edu (Mercury 1.11); 

Tue, 1 Aug 95 16:38:29 PST8PDT 
Received: from MERCURY_MAILER by FRL (Mercury 1.11); Tue, 1 Aug 95 16:38:23 
PST8PDT 
From: "Johan Forrer" <FORRERJ@frl.orst.edu> 
Organization: Forest Research Lab. Oregon State 
To: hfsig@tapr.org 


Date: Tue, 1 Aug 1995 16:38:14 PST8PDT 

Subject: Re: [HFSIG:508] Re: DWAIT/DTIME/T2 KISS parameter number 
Priority: normal 

X-mailer: PMail v3.0 (R1a) 


Message-ID: <6EF2B78637E@fr1l.orst.edu> 
Hi Walt, 
Good idea. 


I don't think either Timo or I am subsribed there - could 
you do us a favor pse: cross-post and forward any feedback? 


Thanks much. 
--Johan 


>In your message of 1 Aug 1995 at 1212 CDT, you write: 

>> Hi all, 

>> 

>> I am not sure that everyone picked up Timo's question and request for 
help? 

>> 


>> We need to know some information on the KISS protocol: does anyone know 
>> what the KISS parameter (code) for T2/Dwait/Dtime is? 
>> Who might know? Any help will be greatly appreciated. 
>> 
>> Thanks in advantage. 
ADAAAAAAAN thats a new one - hi. 


>> 
>> --Johan, KC7WW 
>> 
>> 
>> 


>I'm not at home now so can't get the information but Timo might try 
>sending the request to nos-bbs@hydra.carleton.ca or tcp-group@ucsd.edu 
> 
>73, Walt/K5YFW 
From k5yfw@sacdm10.kelly.af.mil Wed Aug 02 08:10:24 1995 
Received: from sacdmi0.kelly.af.mil (sacdm10.kelly.af.mil [137.242.64.10]) by 
dingus.n5lyt.datarace.com (8.6.12/8.6.9) with SMTP id IAA08454 for 
<hfsig@tapr.org>; Wed, 2 Aug 1995 08:10:11 -0500 
Received: by sacdm10.kelly.af.mil (Smail3.1.29.0 #2) 
id mOsddHp-000299C; Wed, 2 Aug 95 07:52 CDT 
Message-Id: <mOsddHp-000299C@sacdm10.kelly.af.mil> 
Date: Wed, 2 Aug 95 07:52:37 -0500 
From: k5yfw@sacdm10.kelly.af£.mil (WALT DUBOSE - K5YFW) 
Subject: Re: [HFSIG:509] Re: DWAIT/DTIME/T2 KISS parameter number 
To: tcp-group@ucsd.edu 
Cc: hfsig@tapr.org 
X-orig-date: Tue, 1 Aug 1995 18:44:19 -0500 
X-orig-from: "Johan Forrer" <FORRERJ@frl.orst.edu> 
X-orig-message-ID: <6EF2B78637E@frl.orst.edu> 


Could someone answer Timo's question and send the reply to: 
hfsig@tapr.org 

Thanks, Walt/K5YFW 

In Timo's message of 1 Aug 1995 at 11212 CDT, he writes: 

I need to know some information on the KISS protocol: does anyone know 


what the KISS parameter (code) for T2/Dwait/Dtime is? 
Who might know? Any help will be greatly appreciated. 


VVVV Vv 


> Thanks in advance, Timo 

From wd6éehr@kaiwan.com Wed Aug 02 12:57:22 1995 

Received: from kaiwan.kaiwan.com (kaiwan.kaiwan.com [198.178.203.2]) by 
dingus.n5lyt.datarace.com (8.6.12/8.6.9) with ESMTP id MAA11570 for 
<hfsig@tapr.org>; Wed, 2 Aug 1995 12:57:17 -0500 

Received: from kaiwan009.kaiwan.com (2070@kaiwan009.kaiwan.com [198.178.203.9]) by 
kaiwan.kaiwan.com (8.6.12/8.6.12) with ESMTP 


id KAA17382 for <hfsig@tapr.org>; Wed, 2 Aug 1995 10:57:08 -0700 
xxx KAIWAN Internet Access xxx 
Received: (from wd6ehr@localhost) by kaiwan009.kaiwan.com (8.6.9/8.6.9) 
id KAA13871 for hfsig@tapr.org; Wed, 2 Aug 1995 10:57:10 -0700 
xxx KAIWAN Internet Access xxx 
From: Mike Curtis <wd6ehr@kaiwan.com> 
Message-Id: <199508021757 .KAA13871@kaiwan009.kaiwan.com> 
Subject: re: DWAIT and KISS 
To: hfsig@tapr.org 
Date: Wed, 2 Aug 1995 10:57:10 -0700 (PDT) 
X-Mailer: ELM [version 2.4 PL22] 
MIME-Version: 1.0 
Content-Type: text/plain; charset=US-ASCII 
Content-Transfer-Encoding: 7bit 
Content-Length: 196 


There is no DWAIT in KISS (fortunately!) It has been replaced by persist 
and slottime, which is vastly superior to the old DWAIT parameter. Also, 
Ppersist is incompatible with DWAIT. 


-- mike 
From karn@qualcomm.com Wed Aug 02 17:08:09 1995 
Received: from servo.qualcomm.com (servo.qualcomm.com [129.46.128.14]) by 
dingus.n5lyt.datarace.com (8.6.12/8.6.9) with ESMTP id RAA14776 for 
<hfsig@tapr.org>; Wed, 2 Aug 1995 17:07:52 -0500 
Received: (karn@localhost) by servo.qualcomm.com (8.6.12/QC-BSD-2.5) id PAA29619; 
Wed, 2 Aug 1995 15:07:45 -0700 
Date: Wed, 2 Aug 1995 15:07:45 -0700 
From: Phil Karn <karn@qualcomm. com> 
Message-Id: <199508022207 .PAA29619@servo.qualcomm. com> 
To: hfsig@tapr.org 
Subject: FFT speeds? 


I wasn't happy with any of the FFT routines I found on the net or in 
textbooks, so over the weekend I wrote up one in C. It does a 256-point 
double precision complex FFT in 870 microseconds on the Pentium 90 

and 3.34 milliseconds on the AMD 486DX4-100. Anybody have some comparative 
speed figures? 


Phil 


From FORRERJ@frl.orst.edu Wed Aug 02 18:01:56 1995 
Received: from amanda.bus.orst.edu (amanda.BUS.ORST.EDU [128.193.10.36]) by 
dingus.n5lyt.datarace.com (8.6.12/8.6.9) with ESMTP id SAA15482 for 
<hfsig@tapr.org>; Wed, 2 Aug 1995 18:01:43 -0500 
Received: from frl.orst.edu (FRL.ORST.EDU [128.193.226.10]) by amanda.bus.orst.edu 
(8.6.9/8.6.9) with SMTP id QAA01464 for <hfsig@tapr.org>; Wed, 2 Aug 1995 16:01:29 
-0700 
Received: from FRL/MERCURY_MAILER by frl.orst.edu (Mercury 1.11); 

Wed, 2 Aug 95 16:06:32 PST8PDT 
Received: from MERCURY_MAILER by FRL (Mercury 1.11); Wed, 2 Aug 95 16:06:21 
PST8PDT 


From: "Johan Forrer" <FORRERJ@frl.orst.edu> 
Organization: Forest Research Lab. Oregon State 
To: hfsig@tapr.org 


Date: Wed, 2 Aug 1995 16:06:16 PST8PDT 
Subject: Re: [HFSIG:512] FFT speeds? 
Priority: normal 

X-mailer: PMail v3.0 (Ria) 


Message-ID: <706A3735912@frl.orst.edu> 
Phil, 


> I wasn't happy with any of the FFT routines I found on the net or in 

> textbooks, so over the weekend I wrote up one in C. It does a 256-point 

> double precision complex FFT in 870 microseconds on the Pentium 90 

> and 3.34 milliseconds on the AMD 486DX4-100. Anybody have some comparative 
> speed figures? 

> 

> 


Phil 


Could you tell us whether this is floating point or integer, and what 
radix ? Sounds very impressive. Just for sake of comparison, 

the 12 mHz ADSP-21xx benchmark for a Radix 4, 256 point integer FFT is 
590 us. The 1024 point R4 checks in at 2.98 ms. Radix 2 is nearly double 
those figures. All these are complex, 16-bit data words. 


I am sure that you will get a reasonable answer if you post this question 
to COMP.DSP - this is a popular topic. 


--Johan 


From kurpiers@zeus.uet.e-technik.th-darmstadt.de Thu Aug 03 02:02:19 1995 
Received: from rs2.hrz.th-darmstadt.de (rs2.hrz.th-darmstadt.de [130.83.22.63]) by 
dingus.n5lyt.datarace.com (8.6.12/8.6.9) with SMTP id CAA20878 for 
<hfsig@tapr.org>; Thu, 3 Aug 1995 02:02:07 -0500 
Received: from zeus (zeus.uet.e-technik.th-darmstadt.de) by rs2.hrz.th- 
darmstadt.de with SMTP id AA26851 

(5.65c/IDA-1.4.4 for <hfsig@tapr.org>); Thu, 3 Aug 1995 09:01:17 +0200 
Received: from hades (hades.uet.e-technik.th-darmstadt.de [130.83.18.78]) by zeus 
(8.6.9/8.6.9-HRZ) with ESMTP id JAA20568 for <hfsig@tapr.org>; Thu, 3 Aug 1995 
09:01:17 +0200 
From: Alexander Kurpiers <kurpiers@zeus.uet.e-technik.th-darmstadt.de> 
Received: (kurpiers@localhost) by hades (8.6.9/8.6.9-HRZ-Fwd2.0) id JAA18701 for 
hfsig@tapr.org; Thu, 3 Aug 1995 09:01:10 +0200 
Message-Id: <199508030701.JAA18701@hades> 
Subject: re: DWAIT and KISS 
To: hfsig@tapr.org 
Date: Thu, 3 Aug 1995 09:01:04 +0200 (MESZ) 
In-Reply-To: <199508021757 .KAA13871@kaiwan009.kaiwan.com> from "Mike Curtis" at 
Aug 2, 95 01:01:53 pm 
X-Mailer: ELM [version 2.4 PL24] 
Mime-Version: 1.0 
Content-Type: text/plain; charset=US-ASCII 
Content-Transfer-Encoding: 7bit 


Content-Length: 1093 


> 

> There is no DWAIT in KISS (fortunately!) It has been replaced by persist 
> and slottime, which is vastly superior to the old DWAIT parameter. Also, 
> Ppersist is incompatible with DWAIT. 

> 


-- mike 


VV WV 


Actually the problem (at least with some implementations of KISS on TNC2) 
is, that they do not start with the slottime. Depending on the 
persistance setting these KISS versions start to transmit immediately 
after DCD is gone. 

Better would be to wait at least one time slottime before starting 

the persistance algorithm. 


Alexander 

Foes Ses eee see eee te eee ee Pos eS sede eee eee ee eee es * 
| Alexander F. Kurpiers | | 
| Institut f. Uebertragungstechnik | Voice: +49-6151-162369 | 
| u. Elektroakustik | Fax : +49-6151-165545 

| Merckstrasse 25 | EMail: a.kurpiers@uet.th-darmstadt.de | 
| D-64283 Darmstadt (Germany) | Hamradio: dl8aau@db0eam.#thes.deu.eu 

ee a Sete aoe ieee ee eye ieee fee reser ee See eee ea eee a eee es * 


From Sivula@ncsmsg01es.ntc.nokia.com Thu Aug 03 04:31:52 1995 
Received: from axl01it.ntc.nokia.com (axl01it.ntc.nokia.com [131.228.118.232]) by 
dingus.n5lyt.datarace.com (8.6.12/8.6.9) with ESMTP id EAA21247; Thu, 3 Aug 1995 
04:31:45 -0500 
Received: from ntciteO1es.ntc.nokia.com (ms-smtp-gw.tele.nokia.fi 
[131.228.138.80]) by axlO1it.ntc.nokia.com (8.6.9/8.6.9) with SMTP id MAA24328; 
Thu, 3 Aug 1995 12:30:14 +0300 
Received: by ntciteO01es.ntc.nokia.com with Microsoft Mail 
id <3020A5AE@ntciteO1les.ntc.nokia.com>; Thu, 03 Aug 95 12:32:14 eet 
From: Sivula Timo <Sivula@ncsmsg01es.ntc.nokia.com> 
To: "'HFSIG'" <hfsig@tapr.org>, "'TAPR-TNC'" <tapr-tnc@tapr.org> 
Subject: T2/Dwait/Dtime 
Date: Wed, 02 Aug 95 09:25:00 eet 
Message-ID: <3020A5AE@ntcite01es.ntc.nokia.com> 
Encoding: 21 TEXT 
X-Mailer: Microsoft Mail V3.0 


Hello, 


I checked some documents out and found that Dtime and Dwait are one 
parameter and T2 is another. T2 simply seems to be the parameter which is 


called Resptime in for instance the G8BPQ manual. 


Dwait and Dtime is according to the TheFirmware 2.6 manual a parameter that 
puts a waiting time between the moment when the transmission is intended to 
start to the moment when it is really starting. This is the parameter for 
which I would need the KISS parameter code. 


According to the TF manual dwait/dtime is using the value of one timslot of 
the persistence algorithm. Thus the modification consist of simply adding 
one timeslot before every transmisson. I have seen this time beeing 
independently adjustable in some applications, so I would like to be sure 
about how the parameter really works and to get the KISS code for it, if 
there is one. 


Timo 


From Danny@edstks1.demon.co.uk Thu Aug 03 13:12:54 1995 

Received: from disperse.demon.co.uk (disperse.demon.co.uk [158.152.1.77]) by 

dingus.n5lyt.datarace.com (8.6.12/8.6.9) with SMTP id NAA26366 for 

<hfsig@tapr.org>; Thu, 3 Aug 1995 13:12:46 -0500 

Received: from post.demon.co.uk by disperse.demon.co.uk id aaQ1858; 
3 Aug 95 18:13 +0100 

Received: from edstks1.demon.co.uk by post.demon.co.uk id aa02140; 
3 Aug 95 18:10 +0100 

Date: Thu, 03 Aug 1995 17:32:23 GMT 

From: Danny Higgins <Danny@edstks1.demon.co.uk> 

Reply-To: Danny@edstks1.demon.co.uk 

Message-Id: <229@edstks1.demon.co.uk> 

To: hfsig@tapr.org 

Subject: Robust modems 

X-Mailer: PCElm 1.10 

Lines: 121 


Hi, Johan, and many thanks for pointing me at HFSIG. 
I've downloaded the discussions for the past year, and I have a lot of reading 
to do! 


Let me introduce myself. I have been active on HF for 27 years now, mainly CW, 
and my main interest is chasing DX with modest power and a small garden. I have 
never owned a linear or a beam but I wouldn't call myself a QRP fanatic. My 
interest is in robust, reliable HF communications, both professionally and at 
home. This has tended towards robust slow speed data, not high speed data 
transfer which is available via internet, etc. 


For many years now I have been interested in coherent CW as a robust HF 
modulation system. Over the years I have been involved in several projects at 
work which could lend themselves to improving the CCW waveform. 


Basic CCW requires 100 milliseconds for a dot, 300 milliseconds for a dash, 
with the gaps between dots and dashes as exact multiples of 100 milliseconds, 
giving a Morse speed of 12 WPM. The difficulty with this is the frequency 
accuracy required and the synchronisation between both ends of the link. In 
practice, a 9Hz wide non-ringing integrate and dump filter can be used 


effectively to detect the tones once the signal has been found. The integrate 
and dump filter compares its output at the end of every dot period with the 
no-signal condition to determine if the carrier was present. 


Imagine now the effect of sending a different tone for the key-up condition. 
This signal would be 10Hz away from the key-down signal (assuming a 100 
millisecond dot length, since the tones must be orthogonal). The key-up signal 
is effectively another CCW signal which can be detected in the same way, but 
now the data decision is based on the difference between the key-up and 
key-down tone detectors. This must give a 3 dB improvement in signal to noise 
ratio at the expense of another coherent tone detector (free if you are using 
DSP!). This is a 2 tone version of the 32 tone Piccolo system. 


There is still the problem of synchronisation. Instead of having one tone for 
key-up and another tone for key-down, suppose that a pair of tones are used, 
each lasting 50 milliseconds and they must now be 20Hz apart to retain 
orthogonality. Let the tones be called Mark (M) and Space (S). Let a DOT be 
represented by "SS" and a DASH be represented by "MM". The key-up condition 
can be represented by: 

"MSMSMSMSMSMS...." 


The sequence "SM" is invalid and shows that either an error has occurred or 
the system is out of sync. 


The receiving system can automatically synchronise to a stream of 
"....MSMSMSMS..." tones at the start of a transmission. Three detectors can 

be used at the decoder, one sampling early, one in the middle and one sampling 
late. The relative outputs of these detectors can be used to automatically 
advance and retard the sampling signals to achieve synchronisation (again this 
is cheap in DSP but expensive in a custom hardware solution). 


Since a DASH contains no more information than a DOT there is no reason for it 
to be 3 times longer. The gap between DOTS and DASHES also does not need to be 
sent, since the detector can uniquely identify them. The word "PARIS" for 
example would be: 

"SSMMMMSSMSSSMMMSSSMMSSMSSSSSMSSSSSSS" 


using "MS" to define the boundary between individual letters. This coding 
gives an effective 36 WPM based on the current Morse alphabet and a 100 
millisecond tone pair sequence. In practice this can be improved further 

still because the original Morse alphabet was devised with a DASH being 3 
times longer than a DOT. In this system the time taken to send the letter "I" 
is the same as the time taken to send to letter "M", so a more optimum coding 
system could be devised based on the frequency of use of all characters 
(including numbers). The complexity of the code doesn't matter because it 

will all be done by the machine. The code could also be extended to have short 
unique sequences for commonly used combinations of characters (e.g. QTH, QSY, 
599, etc.). A speed in excess of 40 or 50 WPM could easily be achieved and the 
50 millisecond tone length, which is a long time on HF, is much longer than 
any path delays therefore there should be no inter-symbol interference. This 
system is basically a 2 tone version of 6 tone Piccolo (LA1117). 


Having produced a code with 20Hz shift, it is possible to chop this with a 


pseudo random sequence (direct sequence spread spectrum) in such a way that 
the signal occupies a 3 kHz bandwidth. It is theoretically possible to obtain 
about 30 dB of signal to interference rejection this way, on top of the 
processing gain already achieved by coherent detection. Different QSOs could 
co-exist in the same channel if different spreading codes are used, or 
narrowband signals could be retained for spectrum efficiency (it is also 
easier to hear someone calling CQ). 


Error detecting and correcting codes could also be applied for additional 
robustness. 


I have worked for 3 UK communications companies, two using Piccolo on HF and 
the other using narrowband (<3 kHz) direct sequence spread spectrum on HF. 
It would be nice to combine the advantages of both. 


This note is very similar to one sent to Jim Mortenson, N2HOS, at the American 
Digital Radio Society (to which I now subscribe) and may be printed in the 
July issue. 


On the subject of DSP platforms, I have just purchased a P38 DSP modem card 
from HAL Communications, and have the EVM5X evaluation module for the 
TMS320C50. Since the software is all downloadable from the PC, it should be 
possible for someone to implement something like this to run on existing 
hardware and therefore get a lot of people up and running fast with these new 
modes. This was always the problem with the old CCW system, since it required 
people to build filters which were inflexible. What about a stand-alone box 
with a morse input and output which would plug into a rig and not require a 
computer? 


On the subject of external frequency standard inputs for amateur receivers 
- beware that some rigs use an internal standard for the synthesizer, then 
mix it with a free running crystal oscillator to get it on the right band! 


On the subject of time standards - yes a cheap MSF (a UK 60 kHz time standard 
transmission) receiver can be built and software exists to take the demodulated 
time signal through a pin on the printer socket to automatically update the PC 
clock. (This can then be used in a system to monitor the international 
chirpsounder network on quiet spot frequencies using a matched DSP filter to 
identify particular emitters by their time/frequency offset and provide 
real-time frequency propagation information). 


Keep up the good work!! 


73s for now, de Danny Higgins, G3XVR 


Danny Higgins 

From jreuter@lykos.tng.oche.de Thu Aug 03 14:44:33 1995 

Received: from campino.informatik.rwth-aachen.de (campino. Informatik. RWTH- 
Aachen.DE [137.226.225.2]) by dingus.n5lyt.datarace.com (8.6.12/8.6.9) with SMTP 
id 0AA27195 for <hfsig@tapr.org>; Thu, 3 Aug 1995 14:44:00 -0500 

Received: from downtown.oche.de ([194.94.253.3]) by campino.informatik.xrwth- 


aachen.de 

(4.1/campino-8) id AAQ5051; Thu, 3 Aug 95 21:43:43 +0200 
Received: (from jreuter@localhost) by lykos.tng.oche.de id RAAQ4463; Wed, 2 Aug 
1995 17:36:37 GMT 
Date: Wed, 2 Aug 1995 17:36:36 +0000 (GMT) 
From: Joerg Reuter <jreuter@lykos.tng.oche.de> 
To: WALT DUBOSE - K5YFW <k5yfw@sacdm10.kelly.af.mil> 
Cc: hfsig@tapr.org 
Subject: Re: [HFSIG:509] Re: DWAIT/DTIME/T2 KISS parameter number 
In-Reply-To: <mOsddHp-000299C@sacdm10.kelly.af.mil> 
Message-Id: <Pine.LNX.3.91.950802170125 .3628A@lykos.tng.oche.de> 
Mime-Version: 1.0 
Content-Type: TEXT/PLAIN; charset=US-ASCII 


On Wed, 2 Aug 1995, WALT DUBOSE - K5YFW wrote: 


> Could someone answer Timo's question and send the reply to: 
> 
> hfsig@tapr.org 


Is this another mailing list? 


Thanks, Walt/K5YFW 


In Timo's message of 1 Aug 1995 at 11212 CDT, he writes: 

> 

> I need to know some information on the KISS protocol: does anyone know 
> what the KISS parameter (code) for T2/Dwait/Dtime is? 

> Who might know? Any help will be greatly appreciated. 

> 

> Thanks in advance, Timo 


VVVVV VV VV MV 


T2 is an AX.25 Level 2 parameter, not a KISS parameter. If this 
timer expires, the whole received packet will be acknowledged 
trough a RR. A too small T2 will result in an frame-per-frame 
ack. (with TheFirmare below version 2.6 you will sometimes 

see cascades of RR-frames after a frame if you set T2 too low: 
RR1 / RR2 / RR3 / ...) 


DWait --- You probably think of the time the TNC waits after 
DCD went down before it starts to transmit. This is done with 
the P-Persistence (sp?) / Slottime algorithm. 


wait until DCD down <----------------------- 22 errr nnn nnn - + 


| 
| | 
| | 
V AN 
wait until waittime expires 
: optional, implemented in 


| : PEICHL's SCC driver and 
| : the Z8530drv for Linux, 
Vv : perhaps other drivers, 
: too? 
DCD still down? 


| yes 


number below "persistence" value? 


| yes | no 
Vv Vv 
start to transmit wait until slottime expires 
| 
| 
Vv 


DCD still down? 


KISS usually supports at least the following commands: 


Q@ - Data (o£ course!) 
1 - Tx delay (timer) 
2 - persistence (value) 
3 - slottime (timer) 
4 - tx tail (timer) 
5 - fullduplex (flag) 


255 - reset KISS mode (or return to Hostmode) 
all timers in 1/10 s 
Joerg Reuter ampr-net: dlibke@dbOpra.ampr.org 


AX-25 : DLIBKE @ DBOLJ.#RPL.DEU.EU 
Internet: jreuter@lykos.tng.oche.de 


From karn@qualcomm.com Thu Aug 03 15:42:12 1995 

Received: from servo.qualcomm.com (servo.qualcomm.com [129.46.128.14]) by 
dingus.n5lyt.datarace.com (8.6.12/8.6.9) with ESMTP id PAA27790 for 
<hfsig@tapr.org>; Thu, 3 Aug 1995 15:42:08 -0500 

Received: (karn@localhost) by servo.qualcomm.com (8.6.12/QC-BSD-2.5) id NAAQ8011; 
Thu, 3 Aug 1995 13:42:05 -0700 

Date: Thu, 3 Aug 1995 13:42:05 -0700 

From: Phil Karn <karn@qualcomm. com> 

Message-Id: <199508032042 .NAAQ8011@servo.qualcomm. com> 

To: hfsig@tapr.org 

Subject: Remez exchange algorithm code? 


Does anybody have a machine-readable copy of the Remez exchange 
algorithm code for designing FIR filters? There's a FORTRAN listing in 
Rabiner & Gold that I'd like to avoid typing in (and translating to C) 
if possible. SOMEBODY out there must have it, right? 


Phil 

From paul@paccomm.com Thu Aug 03 16:52:04 1995 

Received: from paccomm.com ([163.125.30.1]) by dingus.n5lyt.datarace.com 

(8.6.12/8.6.9) with SMTP id QAA28497 for <hfsig@tapr.org>; Thu, 3 Aug 1995 

16:51:49 -0500 

X-BBS-Msg-Type: P 

Date: Thu, 03 Aug 95 17:50:10 UTC 

Message-Id: <2698@paccomm. com> 

From: paul@paccomm.com 

To: hfsig@tapr.org 

Subject: Re: [HFSIG:516] Robust modems 

In-Reply-To: your message of Thu, 3 Aug 1995 13:28:08 -0500. 
<2664@paccomm. com> 


CCW timing is easy.... 
derive your timing from GPS time. You'll then be accurate to around 
4Ons for the best receivers or a more typical value of 250ns..... 


Paul Evans, W4/G4BKI paul@paccomm.com +1 (813) 874-2980 | \ 


Fax:+1 (813) 872-8696 pick 

Views expressed here are not necessarily those of PacComm / |--\ 

Don't surf the net, SAIL it! / | \ 

Captain of S/V "Spindrift", Dunedin, FL. / |----\ 

Tall rig (58'), Winged Keel (4' 2"), full batten main / | \ 
[---2- [e227 | 

PacComm Packet Radio Systems Nie nicis ei Me ae ] 

4413 N. Hesperides St., Tampa, FL 33614-7618 ree eee Gants ens / 


From forrerj@ucs.orst.edu Thu Aug 03 21:09:02 1995 

Received: from ucs.orst.edu (UCS.ORST.EDU [128.193.4.5]) by 
dingus.n5lyt.datarace.com (8.6.12/8.6.9) with SMTP id VAA30718 for 
<hfsig@tapr.org>; Thu, 3 Aug 1995 21:08:42 -0500 

Received: from p02.tO.monrotel.com by ucs.orst.edu; 
(5.65v3.0/1.1.8.2/24Sep94-1201PM) 


id AAQ8515; Thu, 3 Aug 1995 19:08:34 -0700 
Message-Id: <9508040208.AA08515@ucs.orst.edu> 
X-Sender: forrerj@ucs.orst.edu 
X-Mailer: Windows Eudora Version 1.4.4 
Mime-Version: 1.0 
Content-Type: text/plain; charset="us-ascii" 
Date: Thu, 03 Aug 1995 18:22:09 -0800 
To: hfsig@tapr.org 
From: forrerj@ucs.orst.edu (Johan Forrer) 
Subject: Re: [HFSIG:518] Remez exchange algorithm code? 


>Does anybody have a machine-readable copy of the Remez exchange 
>algorithm code for designing FIR filters? There's a FORTRAN listing in 
>Rabiner & Gold that I'd like to avoid typing in (and translating to C) 
>if possible. SOMEBODY out there must have it, right? 

> 

>Phil 

> 


I uploaded a package to ftp.tapr.org tapr/SIG/hfsig/upload/remez.zip that you 
might want to look at. It contains both 16 and 32-bit versions including C 
source code. The author is Egil Kvaleberg and I think he did a nice job. 


I have a Fortran version as well - it may well be the one in Rabiner and 
Gold, if you are interested in that, let me know. 


--Johan 


From Sivula@ncsmsg01es.ntc.nokia.com Fri Aug 04 02:13:59 1995 
Received: from axl01it.ntc.nokia.com (axl01it.ntc.nokia.com [131.228.118.232]) by 
dingus.n5lyt.datarace.com (8.6.12/8.6.9) with ESMTP id CAA03888; Fri, 4 Aug 1995 
02:13:53 -0500 
Received: from ntcite01es.ntc.nokia.com (ms-smtp-gw.tele.nokia.fi 
[131.228.138.80]) by axlO1it.ntc.nokia.com (8.6.9/8.6.9) with SMTP id KAA21876; 
Fri, 4 Aug 1995 10:12:23 +0300 
Received: by ntciteO01es.ntc.nokia.com with Microsoft Mail 
id <3021D6E2@ntciteO1les.ntc.nokia.com>; Fri, 04 Aug 95 10:14:26 eet 
From: Sivula Timo <Sivula@ncsmsg01es.ntc.nokia.com> 
To: "'HFSIG'" <hfsig@tapr.org>, "'TAPR-TNC'" <tapr-tnc@tapr.org> 
Subject: KISS Info received, Thank you. 
Date: Fri, 04 Aug 95 10:05:00 eet 
Message-ID: <3021D6E2@ntciteO1es.ntc.nokia.com> 
Encoding: 16 TEXT 
X-Mailer: Microsoft Mail V3.0 


Hello everybody! 


I have received awhole bunch of information concerning KISS. Thank you very 
much 

for putting time on this! We have now made the modification to Leonid and 
Beta-testing 

is going on. 


Thus there is no need for more replys. 


Thank you very much, all the help from everyone was very much appreciated. 


Timo OH6KK/OH2LVZ 


From Sivula@ncsmsg01es.ntc.nokia.com Fri Aug 04 02:14:10 1995 
Received: from axl01it.ntc.nokia.com (axl01it.ntc.nokia.com [131.228.118.232]) by 
dingus.n5lyt.datarace.com (8.6.12/8.6.9) with ESMTP id CAA03900 for 
<hfsig@tapr.org>; Fri, 4 Aug 1995 02:14:02 -0500 
Received: from ntcite01es.ntc.nokia.com (ms-smtp-gw.tele.nokia.fi 
[131.228.138.80]) by axl@1it.ntc.nokia.com (8.6.9/8.6.9) with SMTP id KAA21885 for 
<hfsig@tapr.org>; Fri, 4 Aug 1995 10:12:33 +0300 
Received: by ntciteO01es.ntc.nokia.com with Microsoft Mail 
id <3021D6EB@ntciteO1les.ntc.nokia.com>; Fri, 04 Aug 95 10:14:35 eet 
From: Sivula Timo <Sivula@ncsmsg01es.ntc.nokia.com> 
To: "'HFSIG'" <hfsig@tapr.org> 
Subject: RE: [HFSIG:517] Re: DWAIT/DTIME/T2 KISS parameter number 
Date: Fri, 04 Aug 95 10:06:00 eet 
Message-ID: <3021D6EB@ntciteO1les.ntc.nokia.com> 
Encoding: 14 TEXT 
X-Mailer: Microsoft Mail V3.0 


>T2 is an AX.25 Level 2 parameter, not a KISS parameter. 


I didn't know that before, but I do know it now! Thanks to everyone 
who bothered answering! 


>I A too small T2 will result in an frame-per-frame 

>ack. (with TheFirmare below version 2.6 you will sometimes 
>see cascades of RR-frames after a frame if you set T2 too low: 
>RR1 / RR2 / RR3 / ...) 


To me it seems like most KISS TNC's do this anyway. 


Timo 

From karn@qualcomm.com Fri Aug 04 05:34:50 1995 

Received: from unix.ka9q.ampr.org (unix.ka9q.ampr.org [129.46.90.35]) by 
dingus.n5lyt.datarace.com (8.6.12/8.6.9) with ESMTP id FAA0Q4766 for 
<hfsig@tapr.org>; Fri, 4 Aug 1995 05:34:45 -0500 

Received: (from karn@localhost) by unix.ka9q.ampr.org (8.6.12/8.6.12) id DAA08159; 
Fri, 4 Aug 1995 03:34:37 -0700 

Date: Fri, 4 Aug 1995 03:34:37 -0700 

From: Phil Karn <karn@unix.ka9q.ampr.org> 

Message-Id: <199508041034.DAAQ8159@unix.ka9q.ampr.org> 

To: FORRERJ@fxr1.orst.edu 

CC: hfsig@tapr.org 

Reply-To: karn@qualcomm.com 

In-reply-to: <706A3735912@frl.orst.edu> (FORRERJ@fr1l.orst.edu) 

Subject: Re: [HFSIG:513] Re: FFT speeds? 


>Could you tell us whether this is floating point or integer, and what 
>radix ? Sounds very impressive. Just for sake of comparison, 


Floating point -- double precision. The butterflies are all radix 2, 
though I do optimize out the complex multiplies in the cases where the 
twiddle factors are 1 and -j. Avoiding the complex multiply in the 
latter case is what gives the radix 4 FFT most of of its advantage. 


Wednesday night I used it in a bandpass filter that works by fast 
convolution with overlap+tadd. It's a hack I needed to filter some test 
audio that I'm working into a digital voice demo to complement the one 
I already did for CW vs PSK with FEC. The idea is to produce a 
synthetic noisy SSB signal that uses the same satellite transponder 
energy as a vocoded speech signal at some data rate (either 13kb/s for 
the GSM coder or 8kb/s for the Qualcomm QCELP coder) over a modem with 
some specified EB/NO. 


The big question in any power efficiency comparison of digital voice 
to SSB is the target audio S/N ratio to be used in the comparison. If 
a high S/N ratio is required, the digital scheme is clearly the 
Winner. But if people are willing to tolerate very low SSB S/N 
ratios, it's harder for the digital scheme to save power. And I have a 
rather poor quantitative feel for what various SSB S/Ns really sound 
like, hence my experiments. 


Phil 


From FORRERJ@frl.orst.edu Fri Aug 04 10:26:26 1995 
Received: from amanda.bus.orst.edu (amanda.BUS.ORST.EDU [128.193.10.36]) by 
dingus.n5lyt.datarace.com (8.6.12/8.6.9) with ESMTP id KAAQ7813 for 
<hfsig@tapr.org>; Fri, 4 Aug 1995 10:26:20 -0500 
Received: from frl.orst.edu (FRL.ORST.EDU [128.193.226.10]) by amanda.bus.orst.edu 
(8.6.9/8.6.9) with SMTP id IAA10786 for <hfsig@tapr.org>; Fri, 4 Aug 1995 08:26:02 
-0700 
Received: from FRL/MERCURY_MAILER by frl.orst.edu (Mercury 1.11); 

Fri, 4 Aug 95 8:31:08 PST8PDT 
Received: from MERCURY_MAILER by FRL (Mercury 1.11); Fri, 4 Aug 95 8:30:54 PST8PDT 
From: "Johan Forrer" <FORRERJ@frl.orst.edu> 
Organization: Forest Research Lab. Oregon State 
To: hfsig@tapr.org 


Date: Fri, 4 Aug 1995 08:30:53 PST8PDT 
Subject: Re: [HFSIG:516] Robust modems 
Priority: normal 

X-mailer: PMail v3.0 (Ria) 


Message-ID: <72FOD5C7F2D@frl.orst.edu> 
Hi Danny, 


First - let me welcome both you and Paul Evans to HFSIG. We are looking 
forward sharing in your ideas and talents. 


I have had several requests lately from folks that read this SIG asking for 


more basic materials at a level for the average ham. This is something that 
I intend doing for future HFSIG columns in PSR, however, once I have a 

bit more free time - so please be patient in the mean time. That brings me 
to CCWW: 


CCW, in my opinion, is probably one of the neatest ways of learning DSP 
from the ground up. Especially now with these low-cost EVM's, and all those 
DSP-93's out there, maybe the time is ripe for someone like you to develop 
some DSP code and write about it so that we can get more folks involved and 
participating. 


I am aware of at least two CCW programs out there - one is based on the 
work of Bill de Carle, VE2IQ (?) that runs on a PC and uses his very simple 
sigma-delta A/D convertor (described in QST and QEX). The output of this 
program is computer-generated tones - the operator still has to decode the 
CW by ear though. This would be a great first step to learn DSP principles - 
mostly, common sense is involved (assuming the operator can decode CW by 
ear). Then there is another CCW program by a DL ham (sorry I don't recall 
his name) that takes this another step further - it actually decodes and 
prints the Cw. 


Your suggestion of a two-tone signalling system sounds intriguing - 
however, we loose the ability to decipher the CW by ear. Hold the thought 
for the moment - I like your idea for extending CCW to a narrow-band SS 
system. This may perhaps be the breakthrough that we are waiting for! How 
does it sound, if after you get regular CCW working, implementing the SS 
feature. Regular narrow-band CCW is used to call CQ, sinchronise and 
establish the link - the mode is then switched over to SS. The main 
requirement is that it must be possible for monitoring the transmission by 
a third party - I am sure that with some ingenuity, this may be possible. 
It probably will require that US amateurs apply for STA to participate, but 
would'nt that be a wonderful opportunity to get exposed to these 
contemporary concepts? 


Good luck with your project. Keep us posted on your progress and let us 
know how we can help. 


73's 


--Johan, KC7WW 


From karn@qualcomm.com Fri Aug 04 17:20:29 1995 

Received: from servo.qualcomm.com (servo.qualcomm.com [129.46.128.14]) by 
dingus.n5lyt.datarace.com (8.6.12/8.6.9) with ESMTP id RAA12320 for 
<hfsig@tapr.org>; Fri, 4 Aug 1995 17:20:24 -0500 

Received: (karn@localhost) by servo.qualcomm.com (8.6.12/QC-BSD-2.5) id PAA17024; 
Fri, 4 Aug 1995 15:20:02 -0700 

Date: Fri, 4 Aug 1995 15:20:02 -0700 

From: Phil Karn <karn@qualcomm. com> 

Message-Id: <199508042220.PAA17024@servo.qualcomm. com> 

To: paul@paccomm.com 

CC: hfsig@tapr.org 


In-reply-to: <2698@paccomm.com> (paul@paccomm.com) 
Subject: Re: [HFSIG:519] Re: Robust modems 


>CCW timing is easy.... 
>derive your timing from GPS time. You'll then be accurate to around 
>40ns for the best receivers or a more typical value of 250ns..... 


Except, of course, for the effects of signal propagation delay... 


Phil 

From chbrain@dircon.co.uk Sun Aug 06 00:46:25 1995 

Received: from felix.dircon.co.uk (felix.dircon.co.uk [193.128.224.10]) by 

dingus.n5lyt.datarace.com (8.6.12/8.6.9) with SMTP id AAA27812 for 

<hfsig@tapr.org>; Sun, 6 Aug 1995 00:46:21 -0500 

Received: by felix.dircon.co.uk id AA22825 

(5.67b/IDA-1.5 for <hfsig@tapr.org>); Sun, 6 Aug 1995 06:45:42 +0100 

Message-Id: <199508060545.AA22825@felix.dircon.co.uk> 

Received: from ac043.pool.dircon.co.uk(193.128.230.43) by amnesiac via smap (V1.3) 
id smaQ22823; Sun Aug 6 06:45:24 1995 

X-Sender: chbrain@dircon.co.uk 

X-Mailer: Windows Eudora Version 1.4.4 

Mime-Version: 1.0 

Content-Type: text/plain; charset="us-ascii" 

Date: Sun, 06 Aug 1995 05:39:48 +0100 

To: hfsig@tapr.org 

From: chbrain@dircon.co.uk (Charles Brain) 

Subject: MIL-STD-188-141A 


If anyone is interested there is a postscript copy of the ALE mil standard 
and a final draft of the proposed H.F data link protocol for use with FS1052 
and some psk code and even some viterbi stuff on.... 


ftp: //atanasoff.nmsu.edu/pub/hft 


"projects don't slip, they just catch up with reality" 


Charles Brain (G4GUO) 
Chelmsford, Essex. 

E-mail chbrain@dircon.co.uk 
POTS +44 (0)1245 353221 

FAX +44 (0)1245 275448 


From karn@unix.ka9q.ampr.org Sun Aug 06 01:06:55 1995 

Received: from unix.ka9q.ampr.org (unix.ka9q.ampr.org [129.46.90.35]) by 
dingus.n5lyt.datarace.com (8.6.12/8.6.9) with ESMTP id BAA27919 for 
<hfsig@tapr.org>; Sun, 6 Aug 1995 01:06:52 -0500 

Received: (from karn@localhost) by unix.ka9q.ampr.org (8.6.12/8.6.12) id XAA10906; 
Sat, 5 Aug 1995 23:06:48 -0700 

Date: Sat, 5 Aug 1995 23:06:48 -0700 

From: Phil Karn <karn@unix.ka9q.ampr.org> 

Message-Id: <199508060606. XAA10906@unix.ka9q.ampr.org> 

To: hfsig@tapr.org, tcp-group@ucsd.edu 


Subject: FEC packages updated 


I've put out updated versions of the Fano and Viterbi decoder packages 
I originally released in March. 


The changes aren't extensive; mostly minor bug fixes and some cosmetic 
reworking. They're described in the new readme files. My web page 


http: //www.qualcomm.com/people/pkarn/ham. html 
has been updated to point to the updated files. 


Note: since the files themselves reside in ftp.ucsd.edu's anonymous 
upload directory, I was unable to overwrite or delete the old 
versions. So I had to create new file names. Flush any old copies you 
may have of the web page mentioned above. 


Phil 


From Danny@edstks1.demon.co.uk Fri Aug 11 08:02:23 1995 
Received: from disperse.demon.co.uk (disperse.demon.co.uk [158.152.1.77]) by 
sysi.tapr.org (8.6.12/8.6.9) with SMTP id IAA15822 for <hfsig@tapr.org>; Fri, 11 
Aug 1995 08:02:08 -0500 
Received: from post.demon.co.uk by disperse.demon.co.uk id aaQ0849; 
11 Aug 95 13:27 +0100 
Received: from edstks1.demon.co.uk by post.demon.co.uk id aa06076; 
11 Aug 95 13:24 +0100 
Date: Fri, 11 Aug 1995 12:38:00 GMT 
From: Danny Higgins <Danny@edstks1.demon.co.uk> 
Reply-To: Danny@edstks1.demon.co.uk 
Message-Id: <236@edstks1.demon.co.uk> 
To: hfsig@tapr.org 
Subject: Re: [HFSIG:524] Re: Robust modems 
X-Mailer: PCElm 1.10 
Lines: 55 


In message <72FOD5C7F2D@frl.orst.edu> hfsig@tapr.org writes: 
Hi again Johan 


CCW, in my opinion, is probably one of the neatest ways of learning DSP 
from the ground up. Especially now with these low-cost EVM's, and all those 
DSP-93's out there, maybe the time is ripe for someone like you to develop 
some DSP code and write about it so that we can get more folks involved and 
participating. 


VVVV WV 


This is the only reason that I want to get into DSP. I am way down the 
learning curve, but I've got the kit and the enthusiasm, all I need now 
is time and knowledge! ! 


> I am aware of at least two CCW programs out there - 


I am aware of these programs, but as you can see I want to take it further. 


> Your suggestion of a two-tone signalling system sounds intriguing - 
> however, we loose the ability to decipher the CW by ear. 


What I suggested was a modem with a morse key input and loudspeaker output 
which sent the reconstituted morse back to the operator, using a FIFO to 
balance out the speed differences. With about 50 WPM capability, I reckon 
the modem would spend most of its time idling! 


> Hold the thought for the moment - 

>I like your idea for extending CCW to a narrow-band SS 

system. This may perhaps be the breakthrough that we are waiting for! How 
does it sound, if after you get regular CCW working, implementing the SS 
feature. Regular narrow-band CCW is used to call CQ, sinchronise and 
establish the link - the mode is then switched over to SS. The main 
requirement is that it must be possible for monitoring the transmission by 
a third party - I am sure that with some ingenuity, this may be possible. 
It probably will require that US amateurs apply for STA to participate, but 
would'nt that be a wonderful opportunity to get exposed to these 
contemporary concepts? 


VVVNVVV VV WV 


The Piccolo modem by Adrian Nash would form the basis for this type of CCW 
system if it only used 2 tones. I'm trying to get in touch with him since 
he is transporting it to the TMS320C50 which I use. Alternatively, why not 
keep all 6 tones and still apply direct sequence spread spectrum? 


The spreading code would be chosen for its autocorrelation properties, not 
as a means of "encrypting" data. The codes would therefore be in the public 
domain. Experimental licences have been granted over here, but mainly for 
VHF work. I see no reason for not applying this to HF, as long as the signal 
was band limited to about 2 or 3 kHz, therefore not requiring a special IF 
filter in the receiver/transmitter. I wonder how long it will be before Ham 
rigs will generally have DSP IF filters to get round some of these problems. 


73s de Danny Higgins, G3XVR 
From Danny@edstks1.demon.co.uk Fri Aug 11 08:03:06 1995 
Received: from disperse.demon.co.uk (disperse.demon.co.uk [158.152.1.77]) by 
sysi.tapr.org (8.6.12/8.6.9) with SMTP id IAA15846 for <hfsig@tapr.org>; Fri, 11 
Aug 1995 08:03:01 -0500 
Received: from post.demon.co.uk by disperse.demon.co.uk id aaQ0883; 
11 Aug 95 13:28 +0100 
Received: from edstks1.demon.co.uk by post.demon.co.uk id aa06190; 
11 Aug 95 13:25 +0100 
Date: Fri, 11 Aug 1995 12:52:41 GMT 
From: Danny Higgins <Danny@edstks1.demon.co.uk> 
Reply-To: Danny@edstks1.demon.co.uk 
Message-Id: <237@edstks1.demon.co.uk> 
To: hfsig@tapr.org 
Subject: Re: [HFSIG:525] Re: Robust modems 
X-Mailer: PCElm 1.10 


Lines: 20 
Hi, Phil. 


>CCW timing is easy.... 

>derive your timing from GPS time. You'll then be accurate to around 
>40ns for the best receivers or a more typical value of 250ns..... 

> 

> Except, of course, for the effects of signal propagation delay... 
> 

> Phil 

> 


You could end up paying more for GPS than for the modem! I would hope to 
build a small stand alone modem for use with any transceiver. 


As someone else pointed out before, if you use GPS timing then you could 
use the propagation delay to select (or reject!) signals from particular 
areas. 


73s de Danny Higgins, G3XVR 
From Danny@edstks1.demon.co.uk Fri Aug 11 08:07:59 1995 
Received: from disperse.demon.co.uk (disperse.demon.co.uk [158.152.1.77]) by 
sysi.tapr.org (8.6.12/8.6.9) with SMTP id IAA15909 for <hfsig@tapr.org>; Fri, 11 
Aug 1995 08:07:48 -0500 
Received: from post.demon.co.uk by disperse.demon.co.uk id aaQQ795; 
11 Aug 95 13:27 +0100 
Received: from edstks1.demon.co.uk by post.demon.co.uk id aa05988; 
11 Aug 95 13:24 +0100 
Date: Fri, 11 Aug 1995 12:34:42 GMT 
From: Danny Higgins <Danny@edstks1.demon.co.uk> 
Reply-To: Danny@edstks1.demon.co.uk 
Message-Id: <235@edstks1.demon.co.uk> 
To: hfsig@tapr.org 
Subject: Re: [HFSIG:519] Re: Robust modems 
X-Mailer: PCElm 1.10 
Lines: 10 


In message <2698@paccomm.com> hfsig@tapr.org writes: 

> CCW timing is easy.... 

> derive your timing from GPS time. You'll then be accurate to around 
> 40ns for the best receivers or a more typical value of 250ns..... 


Fine, but you will spend more on GPS than I inteded to on the modem! 
I would like to make this an external box which went with any transceiver. 


Danny Higgins 

From sadowskp@usafcrqs.nellis.af.mil Fri Aug 11 10:04:43 1995 

Received: from bncc.nellis.af.mil ([132.58.120.19]) by sys1.tapr.org 
(8.6.12/8.6.9) with SMTP id KAA17504 for <hfsig@tapr.org>; Fri, 11 Aug 1995 
10:04:37 -0500 


Received: from mailgtwy.nellis.af£f.mil by bncc.nellis.af.mil with SMTP 
(1.38.193.4/16.2) id AA22022; Fri, 11 Aug 1995 08:15:27 -0700 
Received: by mailgtwy.nellis.af.mil with Microsoft Mail 
id <302B4A05@mailgtwy.nellis.af.mil>; Fri, 11 Aug 95 07:16:05 cdt 
From: "Sadowski,P CPT USAF CRQS/RQEN" <sadowskp@usafcrqs.nellis.af£.mil> 
To: hfsig <hfsig@tapr.org> 
Subject: RE: [HFSIG:528] Re: Robust modems 
Date: Fri, 11 Aug 95 07:18:00 cdt 
Message-Id: <302B4A05@mailgtwy.nellis.af£.mil> 
Encoding: 19 TEXT 
X-Mailer: Microsoft Mail V3.0 


The comments about the CCW and SS were very interesting (exactly the 
kind of thing I was hoping to see in this SIG).. I'm looking for info ona 


very Similar topic, CCW but extremely narrow bandwidth - - 10 Hz max.. I 
realize the symbol rate will be slower - but my interested is in sending a 
few "canned" msgs - so an appropriate coding scheme can "compress" 

a heck of a bunch with only a few fixed messages. Mind you, I'm not 


interested in giving up free text altogether... just that I can accept 
serious 

compromise for free text (canned msgs are 95% of need). I'm going to 
show my ignorance here... but what might be the tradeoffs I can expect 


by using SS with low symbol rate vs CCW at low rate? Technology wise, 
error rate, propogation anything else??? 


Thanks in advance 
Al 
AH6LS 
sadowskp@usafcrqs.nellis.af.mil 
From forrerj@ucs.orst.edu Fri Aug 11 12:53:57 1995 
Received: from ucs.orst.edu (UCS.ORST.EDU [128.193.4.5]) by sys1.tapr.org 
(8.6.12/8.6.9) with SMTP id MAA18993 for <hfsig@tapr.org>; Fri, 11 Aug 1995 
12:50:14 -0500 
Received: from p00.tO.monrotel.com by ucs.orst.edu; 
(5.65v3.0/1.1.8.2/24Sep94-1201PM) 
id AAQQ474; Fri, 11 Aug 1995 10:49:47 -0700 
Message-Id: <9508111749 .AAQ0474@ucs.orst.edu> 
X-Sender: forrerj@ucs.orst.edu 
X-Mailer: Windows Eudora Version 1.4.4 
Mime-Version: 1.0 
Content-Type: text/plain; charset="us-ascii" 
Date: Fri, 11 Aug 1995 10:03:59 -0800 
To: hfsig@tapr.org 
From: forrerj@ucs.orst.edu (Johan Forrer) 
Subject: Re: [HFSIG:531] Re: Robust modems 


Dear Al, 


> 
>The comments about the CCW and SS were very interesting (exactly the 


>kind of thing I was hoping to see in this SIG).. 


I agree - if this kind of approach is taken, it would be a breakthough I 
believe. 


>I'm looking for info on a 
>very similar topic, CCW but extremely narrow bandwidth - - 10 Hz max.. 


The rationale behind CCW's narrow filter bandwidth, is that it is optimal 
(not necessarily minimal) for the symbol length. This is what the theory of 
"matched filters" is about. The price that one pays for having such a 
special filter is in the compexity in technology/algorithms that precisely 
extracts where each symbol start/end, and in addition maintain that with 
vengance. This is where men and the mice are separated. 


>I 

>realize the symbol rate will be slower - but my interested is in sending a 
>few "canned" msgs - so an appropriate coding scheme can "compress" 

>a heck of a bunch with only a few fixed messages. Mind you, I'm not 
>interested in giving up free text altogether... just that I can accept 
>serious 

>compromise for free text (canned msgs are 95% of need). 


Not a bad idea - the "Q" code was intended to do that anyway. 


>I'm going to 

>show my ignorance here... but what might be the tradeoffs I can expect 
>by using SS with low symbol rate vs CCW at low rate? Technology wise, 
>error rate, propogation anything else??? 

> 

>Thanks in advance 

>Al 

>AH6LS 

>sadowskp@usafcrqs.nellis.af.mil 

> 


I am as ignorant, but let me have a shot at it - I'll let those more 
knowledgeable correct me please. 


These are two different concepts: 


CCW is a form of coherent demodulation/detection. All that is achieved is 
optimal receiving conditions for detecting a signal, given the 

signal-to-noise ratio. There is no built-in error detection/correction when 

QSB or QRM sets in (except of course that when you dechiper CW by ear, one 

tend to "fill in the blanks" and thus intentionally are doing some form of ECC). 
Summarized: its strenghts is optimal signal detection for a given S/N. If 

there is spare S/N, i.e., good conditions (this probably includes conditions 
where regular CW at the same speed would be pretty tough), very low power 

can be used. There is nothing special about the emitted CW bandwidth - it is 

a regular on-off keyed waveform at the given symbol rate. If there is QRM on 


identically the same frequency, thoughput goes down to zero. 


SS is a signal spreading mode: Instead of having all the signal energy 
concentrated at one frequency, it gets spread out over a much wider band of 
frequencies - a couple of kiloherz or megaherz depending. The result is that 
a certain degree of redundancy enters the picture - if some portion of the 
signal gets blanked out by QRM, or perhaps by selective fading, there 
hopefully remains sufficient signal integrity to detect and demodulate the 
signal. Once the signal is demodulated into baseband (audio), one can still 
use matched filters as for CCW and enjoy the same gains. 

Summarized: Strengths lays in robustness and ability to withstand a 
substantial degree of interference. When applied wisely, many users may 
share the same spectral space, without one interfering with another. Sounds 
a bit like magic, does'nt it? 


Hope that helps? 
73's 
--Johan, KC7WW 


From Danny@edstks1.demon.co.uk Mon Aug 14 13:25:25 1995 
Received: from disperse.demon.co.uk (disperse.demon.co.uk [158.152.1.77]) by 
sysi.tapr.org (8.6.12/8.6.9) with SMTP id NAA22475 for <hfsig@tapr.org>; Mon, 14 
Aug 1995 13:25:19 -0500 
Received: from post.demon.co.uk by disperse.demon.co.uk id aa11948; 
14 Aug 95 17:53 +0100 
Received: from edstks1.demon.co.uk by post.demon.co.uk id aa20950; 
14 Aug 95 17:50 +0100 
Date: Mon, 14 Aug 1995 17:32:07 GMT 
From: Danny Higgins <Danny@edstks1.demon.co.uk> 
Reply-To: Danny@edstks1.demon.co.uk 
Message-Id: <248@edstks1.demon.co.uk> 
To: hfsig@tapr.org 
Subject: Re: [HFSIG:532] Re: Robust modems 
X-Mailer: PCElm 1.10 
Lines: 34 


SS is a signal spreading mode: Instead of having all the signal energy 
concentrated at one frequency, it gets spread out over a much wider band of 
frequencies - a couple of kiloherz or megaherz depending. The result is that 
a certain degree of redundancy enters the picture - if some portion of the 
Signal gets blanked out by QRM, or perhaps by selective fading, there 
hopefully remains sufficient signal integrity to detect and demodulate the 
signal. Once the signal is demodulated into baseband (audio), one can still 
use matched filters as for CCW and enjoy the same gains. 

Summarized: Strengths lays in robustness and ability to withstand a 
substantial degree of interference. When applied wisely, many users may 
share the same spectral space, without one interfering with another. Sounds 
a bit like magic, does'nt it? 


VV VV VV VV VV VV VV 


If I can throw a little bit of light on SS - 


If you start at the modulator with a clean signal, then spread it over, say a 
3 kHz bandwidth by introducing 180 degree phase changes from a pseudo random 
code sequence at a rate equal to half (?) the bandwidth required, what you 

get is a signal which has a sin(x)/x distribution and sounds quite noiselike. 


When this signal appears at the receiver it will have all kinds of QRM 
superimposed on it, and usually at a much greater amplitude. When the signal 
is de-spread by introducing 180 degree phase changes which are synchronised 

to the code sequence which generated the original SS signal, the effect is to 
concentrate all of the spread signal energy back into a single (or multiple) 
tone modulated waveform, but all of the QRM gets spread by this process, which 
gets you your S/N advantage. 


Hope this simple non-mathematical description helps to explain where the S/N 
advantage comes from. 


73s de Danny Higgins, G3XVR 


From FORRERJ@frl.orst.edu Wed Aug 16 14:59:37 1995 
Received: from amanda.bus.orst.edu (amanda.BUS.ORST.EDU [128.193.10.36]) by 
sysi.tapr.org (8.6.12/8.6.9) with ESMTP id 0AA16174 for <hfsig@tapr.org>; Wed, 16 
Aug 1995 14:59:25 -0500 
Received: from frl.orst.edu (FRL.ORST.EDU [128.193.226.10]) by amanda.bus.orst.edu 
(8.6.9/8.6.9) with SMTP id MAAO7757 for <hfsig@tapr.org>; Wed, 16 Aug 1995 
12:57:49 -0700 
Received: from FRL/MERCURY_MAILER by frl.orst.edu (Mercury 1.11); 

Wed, 16 Aug 95 13:03:24 PST8PDT 
Received: from MERCURY_MAILER by FRL (Mercury 1.11); Wed, 16 Aug 95 13:03:04 
PST8PDT 
From: "Johan Forrer" <FORRERJ@fr1l.orst.edu> 
Organization: Forest Research Lab. Oregon State 
To: hfsig@tapr.org 


Date: Wed, 16 Aug 1995 13:02:55 PST8PDT 
Subject: HFSIG at the Digital Conference 
Priority: normal 

X-mailer: PMail v3.0 (R1a) 


Message-ID: <8539EF744A2@fr1l.orst.edu> 
Greetings, 


Thought I would let everyone know that we are planning a special 
meeting on the topic of HF digital communications at the upcoming Digital 
Conference. 


I will prepare some materials for an update on various projects 

that the folks have been working on, in particular, the parallel OFDM HF 
modem, MFSK (Piccolo) HF modem, and various bits pieces of DSP hardware. 
Time permitting, other interesting technical materials may also be 
presented. However, there will be an opportunity and open invitation to 
bring up your favorite or other pressing matters for discussion. 


Greg also tells me that there would be space for me to set up a demo showing 
off a couple of the DSP projects that have been discussed on this SIG. I 
will bring a laptop and some DSP hardware and give you the opportunity to 
see how far things have come along. 


Please make a special effort to be there - looking forward seeing you. 
73's 


--Johan, KC7WW 


From forrerj@ucs.orst.edu Wed Aug 16 16:56:37 1995 
Received: from ucs.orst.edu (UCS.ORST.EDU [128.193.4.5]) by sys1.tapr.org 
(8.6.12/8.6.9) with SMTP id QAA17382 for <HFSIG@tapr.org>; Wed, 16 Aug 1995 
16:56:33 -0500 
Received: by ucs.orst.edu; (5.65v3.0/1.1.8.2/24Sep94-1201PM) 
id AAQ3688; Wed, 16 Aug 1995 14:56:31 -0700 
Date: Wed, 16 Aug 1995 14:56:31 -0700 (PDT) 
From: Johan Forrer <forrerj@ucs.orst.edu> 
To: HFSIG@tapr.org 
Subject: HFSIG at the Digital Conference 
Message-Id: <Pine.OSF.3.91.950816145337 .17596A-100000@ucs.orst.edu> 
Mime-Version: 1.0 
Content-Type: TEXT/PLAIN; charset=US-ASCII 


Greetings, 


Thought I would let everyone know that we are planning a special 
meeting on HF digital communications at the upcoming Digital 
Conference. 


I will prepare some materials for an update on various projects 

that the folks have been working on, in particular, the parallel OFDM HF 
modem, MFSK (Piccolo) HF modem, and various bits pieces of DSP hardware. 
Time permitting, other interesting technical materials may also be 
presented. However, this is an opportunity and open invitation to 

share your experiences or bring up other pressing matters for discussion. 


Greg also tells me that there would be space to set up a demo showing 

off a couple of the DSP projects that have been discussed on this SIG. I 
will bring a laptop and some DSP hardware and give you the opportunity to 
see how far things have come along. 

Please make a special effort to be there - looking forward seeing you. 


73's 


--Johan, KC7WW 


From danie.brynard@pixie.co.za Thu Aug 17 23:57:53 1995 

Received: from foxbat.pix.za (foxbat.pix.za [196.11.62.105]) by sys1.tapr.org 
(8.6.12/8.6.9) with ESMTP id XAA01849 for <hfsig@tapr.org>; Thu, 17 Aug 1995 
23:57:47 -0500 

Received: from pixie.co.za ([196.11.63.137]) by foxbat.pix.za (8.6.12/8.6.12) with 
SMTP id GAA04197 for <hfsig@tapr.org>; Fri, 18 Aug 1995 06:57:57 +0200 

Date: Fri, 18 Aug 1995 06:57:57 +0200 

Message-Id: <199508180457 .GAA04197@foxbat.pix.za> 

X-Sender: pak03226@pixie.co.za 

X-Mailer: Windows Eudora Version 1.4.4 

Mime-Version: 1.0 

Content-Type: text/plain; charset="us-ascii" 

To: hfsig@tapr.org 

From: danie.brynard@pixie.co.za (Danie Brynard) 

Subject: Re: [HFSIG:535] HFSIG at the Digital Conference 


>Greetings, 

> 

>Thought I would let everyone know that we are planning a special 
>meeting on HF digital communications at the upcoming Digital 
>Conference. 

> 


Ai... wens ek kon julle join ! As julle enige van die conference se goed op 
magnetiese media gaan he, sal jy asb aan my dink ? 


73 danie 


From muphaus@cris.com Mon Aug 21 03:07:39 1995 

Received: from deathstar.cris.com (deathstar-fddi.cris.com [199.3.12.171]) by 
sysi.tapr.org (8.6.12/8.6.9) with ESMTP id DAAQ5306 for <hfsig@tapr.org>; Mon, 21 
Aug 1995 03:07:36 -0500 

Received: from mariner.cris.com by deathstar.cris.com [1-800-745-CRIS (voice) ] 
Errors-To: Muphaus@cris.com 

Received: by mariner.cris.com (4.1) id AA16798; Mon, 21 Aug 95 04:07:33 EDT 
From: muphaus@cris.com (Marv Uphaus) 

Newsgroups: list.tapr.hfsig 

To: hfsig@tapr.org 

Subject: Analog Devices ADSP 2181 Development kit... 

Date: Mon, 21 Aug 1995 02:43:53 -0500 

Organization: Not Organized 

Reply-To: muphaus@cris.com 

Message-Id: <5kDOwM82cCKcO83yn@cris.com> 

References: <199508180457 .GAA04197@foxbat.pix.za> 

Lines: 38 


Johan and All... 
Has anyone seen the Analog Devices ADSP 2181 Development kit...??? 
There's an ad on page 10 of the August 95 issue of Circuit Cellar for the 


kit for $89.00... Looks pretty nice... I have wanted a stand alone board 
with upload capabilities and if the code that Johan and others have already 


developed could be cut over to the 2181 chip, this might be just the thing 


to do some stand alone development... It certainly could be just the 
vehicle to get folks like me who aren't heavy duty programmers to take a 
shot at using some of this code on the air... Personally I keep the ham 


shack and the computer development areas separate and I like the stand 
alone idea... 


Anyone have any feelings for this... For $89.00 it's worth buying one just 
to play with... 


Here's the whole poop... 


ADSP 2181 chip - 33-MIPS with 32KB words of on-chip memory... An AD1847 
stereo audio SoundPort codec... Has an RS-232 port and a dual op-amp for 
signal conditioning and an EPROM socket for on-board code... You get an 


assembler, linker, simulator and PROM formatter in the software category... 


Can be made into a stand alone device... They even give you an RS-232 
cable to go to your PC and a 110V cube to power it... It has Windows 
monitor program to control the whole thing... 


WOW, I think I'm sending in my $89.00 today...!!! 
-- Marv... 


-- For private communications, use my PGP public key -- 
-- available at MIT public key server or "finger" me -- 
-- muphaus@cris.com -- 


"I still think a MegaByte is the most Nine-Lives you can get in your mouth 
at one time." --Morris the Cat, sitting in front of his computer terminal. 
From FORRERJ@frl.orst.edu Mon Aug 21 10:38:43 1995 
Received: from amanda.bus.orst.edu (amanda.BUS.ORST.EDU [128.193.10.36]) by 
sysi.tapr.org (8.6.12/8.6.9) with ESMTP id KAAQ7963 for <hfsig@tapr.org>; Mon, 21 
Aug 1995 10:38:40 -0500 
Received: from frl.orst.edu (FRL.ORST.EDU [128.193.226.10]) by amanda.bus.orst.edu 
(8.6.9/8.6.9) with SMTP id IAA10564 for <hfsig@tapr.org>; Mon, 21 Aug 1995 
08:38:43 -0700 
Received: from FRL/MERCURY_MAILER by frl.orst.edu (Mercury 1.11); 

Mon, 21 Aug 95 8:43:10 PST8PDT 
Received: from MERCURY_MAILER by FRL (Mercury 1.11); Mon, 21 Aug 95 8:42:58 
PST8PDT 
From: "Johan Forrer" <FORRERJ@frl.orst.edu> 
Organization: Forest Research Lab. Oregon State 
To: hfsig@tapr.org 


Date: Mon, 21 Aug 1995 08:42:53 PST8PDT 

Subject: Re: [HFSIG:537] Analog Devices ADSP 2181 Development kit... 
Priority: normal 

X-mailer: PMail v3.0 (R1a) 


Message-ID: <8C74C8A7BD6@frl.orst.edu> 


Hi Marv, 


Thanks for letting us know about the EZ-lite. It certainly represents a 
very potent little DSP - plenty of MIPS and lots of on-chip memory. The 24- 
bit architecture also is somewhat easier to learn than some others. 


However, perhaps you want to hold out getting one until you have seen the 
August QEX for some comparisons. I have been playing with the 

Motorola 56002-based EVM ($150) and the article is about this unit. This 
past weekend I have been testing, and am most impressed, with how the 

high speed HF modem runs on the Motorola EVM. Pawel (SP9VRC) now has a 2500 
bps (without FEC) version that looks very promising. If you are planning on 
attending the DCC, I am planning on showing the setup and give you a first- 
hand opportunity to see what it is about. 


73's 


--Johan 


From muphaus@cris.com Mon Aug 21 11:18:54 1995 

Received: from deathstar.cris.com (deathstar-fddi.cris.com [199.3.12.171]) by 
sysi.tapr.org (8.6.12/8.6.9) with ESMTP id LAAQ8482 for <hfsig@tapr.org>; Mon, 21 
Aug 1995 11:18:49 -0500 

Received: from mariner.cris.com by deathstar.cris.com [1-800-745-CRIS (voice) ] 
Errors-To: Muphaus@cris.com 

Received: by mariner.cris.com (4.1) id AA26473; Mon, 21 Aug 95 12:18:42 EDT 
From: muphaus@cris.com (Marv Uphaus) 

To: hfsig@tapr.org 

Subject: Re: [HFSIG:538] Re: Analog Devices ADSP 2181 Development kit... 

Date: Mon, 21 Aug 1995 11:09:36 -0500 

Organization: Not Organized 

Reply-To: muphaus@cris.com 

Message-Id: <A/KOwM82ciURO83yn@cris.com> 

References: <8C74C8A7BD6@frl.orst.edu> 

In-Reply-To: <8C74C8A7BD6@frl.orst.edu> 

Lines: 21 


Johan and All... 

On Mon, 21 Aug 1995 10:58:31 -0500, you wrote: 

>However, perhaps you want to hold out getting one until you have seen the 
>August QEX for some comparisons. I have been playing with the 

>Motorola 56002-based EVM ($150) and the article is about this unit. 

Too late...! I got so excited that this morning I ordered one just to play 


with... It's being shipped today... I hope you guys have not totally 
abandoned the ADSP 2115 project... At least there is some code out there 


to play with for a small potatoes programmer... 
-- Marv... 


-- For private communications, use my PGP public key -- 
-- available at MIT public key server or "finger" me -- 
-- muphaus@cris.com -- 


"I still think a MegaByte is the most Nine-Lives you can get in your mouth 
at one time." --Morris the Cat, sitting in front of his computer terminal. 
From FORRERJ@frl.orst.edu Mon Aug 21 12:00:31 1995 
Received: from amanda.bus.orst.edu (amanda.BUS.ORST.EDU [128.193.10.36]) by 
sysi.tapr.org (8.6.12/8.6.9) with ESMTP id MAA09165 for <hfsig@tapr.org>; Mon, 21 
Aug 1995 12:00:24 -0500 
Received: from frl.orst.edu (FRL.ORST.EDU [128.193.226.10]) by amanda.bus.orst.edu 
(8.6.9/8.6.9) with SMTP id KAA11161 for <hfsig@tapr.org>; Mon, 21 Aug 1995 
10:00:25 -0700 
Received: from FRL/MERCURY_MAILER by frl.orst.edu (Mercury 1.11); 

Mon, 21 Aug 95 10:04:52 PST8PDT 
Received: from MERCURY_MAILER by FRL (Mercury 1.11); Mon, 21 Aug 95 10:04:26 
PST8PDT 
From: "Johan Forrer" <FORRERJ@frl.orst.edu> 
Organization: Forest Research Lab. Oregon State 
To: hfsig@tapr.org 


Date: Mon, 21 Aug 1995 10:04:17 PST8PDT 

Subject: Re: [HFSIG:539] Re: Analog Devices ADSP 2181 Development ki 
Priority: normal 

X-mailer: PMail v3.0 (R1a) 


Message-ID: <8C8A81B4001@frl.orst.edu> 
Hi Marv, 


No, the ADI-2115 project is alive and well. As a matter of fact, if you 
show up at the DDC, I will be happy to show you some very neat software 

by Adrian, G4ZHZ, for the PSA soundcard. I won't let the cat out 

of the bag. Adrian also has passed on code to run MFSK - I will be 

starting work on getting it ported to the sound card DSP in the near future. 
So, not to worry, there will be plenty of opportunities for you to explore. 


One thing that we have to accept for the moment, is that there will be 
several DSP platforms - it will be a while until we will be able 

to present a written specification for the HF modems that is presently 
being developed. When that time comes, it would be necessary to cross-port 
between these platforms, if that is possible. That possibly may be a 
challenge. Judging from what I have seen going on in the high speed HF 
modem, it would be a tough job to match the 56K's performance - the modem 
is very hungry on cycles, and the benifits of the 24-bit architecture has 
its advantages in dynamic range. Anyway we will have to wait and see how it 
develops. 


I will present further details of these projects at the DDC and at that 
time invite your inputs on some issues that are presently unfolding. 


--Johan, KC7WW 

From paul@paccomm.com Tue Aug 22 09:45:41 1995 

Received: from paccomm.com ([163.125.30.1]) by sysi.tapr.org (8.6.12/8.6.9) with 

SMTP id JAA21064 for <hfsig@tapr.org>; Tue, 22 Aug 1995 09:45:28 -0500 

X-BBS-Msg-Type: P 

Date: Tue, 22 Aug 95 10:38:31 UTC 

Message-Id: <4063@paccomm.com> 

From: paul@paccomm.com 

To: hfsig@tapr.org 

Subject: Re: [HFSIG:540] Re: Analog Devices ADSP 2181 Development ki 

In-Reply-To: your message of Mon, 21 Aug 1995 12:08:28 -0500. 
<3962@paccomm. com> 


Seems like the PTC-II team chose the right DSP to do the HF modem 
job..... the Mot. 


Paul Evans, W4/G4BKI paul@paccomm.com +1 (813) 874-2980 | \ 

Fax:+1 (813) 872-8696 /\ \ 

Views expressed here are not necessarily those of PacComm / |--\ 

Don't surf the net, SAIL it! / |x*«\ 
Captain of S/V "Spindrift", Dunedin, FL. / |----\ 
Catalina 36: Tall rig (58'), Winged Keel (4' 2"), / | \ 
Full batten main, Boston Whaler dinghy. /----- |------ . 
PacComm Packet Radio Systems ee “a------- ] 
4413 N. Hesperides St., Tampa, FL 33614-7618 \ 


From karn@qualcomm.com Tue Aug 22 16:44:37 1995 

Received: from servo.qualcomm.com (servo.qualcomm.com [129.46.128.14]) by 
sysi.tapr.org (8.6.12/8.6.9) with ESMTP id QAA26596 for <hfsig@tapr.org>; Tue, 22 
Aug 1995 16:44:31 -0500 

Received: (karn@localhost) by servo.qualcomm.com (8.6.12/QC-BSD-2.5) id 0AA15733; 
Tue, 22 Aug 1995 14:44:22 -0700 

Date: Tue, 22 Aug 1995 14:44:22 -0700 

From: Phil Karn <karn@qualcomm. com> 

Message-Id: <199508222144 .0AA15733@servo.qualcomm. com> 

To: hfsig@tapr.org 

In-reply-to: <248@edstks1.demon.co.uk> (message from Danny Higgins on Mon, 14 Aug 
1995 13:46:23 -0500) 

Subject: Re: [HFSIG:533] Re: Robust modems 


An additional remark about spread spectrum processing gain -- it's a 
wash on a nonfading AWGN (additive white gaussian noise) channel. A 
spread system has no signal-to-noise advantage over a non spread 
system in this case. 


However, SS wins big in several important real-world situations. 
These include fading channels, and channels with interference 
(intentional or benign). And it's especially helpful where there are 
lots of individual users with traffic that's too bursty to permit the 
efficient reallocation of channels or timeslots on demand. 


Phil 


From karn@qualcomm.com Tue Aug 22 17:05:31 1995 

Received: from servo.qualcomm.com (servo.qualcomm.com [129.46.128.14]) by 
sysi.tapr.org (8.6.12/8.6.9) with ESMTP id RAA26920 for <hfsig@tapr.org>; Tue, 22 
Aug 1995 17:05:21 -0500 

Received: (karn@localhost) by servo.qualcomm.com (8.6.12/QC-BSD-2.5) id PAA15792; 
Tue, 22 Aug 1995 15:05:18 -0700 

Date: Tue, 22 Aug 1995 15:05:18 -0700 

From: Phil Karn <karn@qualcomm. com> 

Message-Id: <199508222205.PAA15792@servo.qualcomm. com> 

To: "Sadowski,P CPT USAF CRQS/RQEN" <sadowskp@usafcrqs.nellis.af.mil> 

CC: hfsig@tapr.org 

In-reply-to: <302B4A05@mailgtwy.nellis.af.mil> (sadowskp@usafcrqs.nellis.af£.mil) 
Subject: Re: [HFSIG:531] Re: Robust modems 


>compromise for free text (canned msgs are 95% of need). I'm going to 
>show my ignorance here... but what might be the tradeoffs I can expect 
>by using SS with low symbol rate vs CCW at low rate? Technology wise, 
>error rate, propogation anything else??? 


In general, SS is better at extremely low rates. Extremely narrowband 
techniques often have problems with carrier frequency uncertainty and 
guard-banding, and SS can be easier to handle in practice. 


Phil 


From FORRERJ@frl.orst.edu Tue Aug 22 17:32:02 1995 
Received: from amanda.bus.orst.edu (amanda.BUS.ORST.EDU [128.193.10.36]) by 
sysi.tapr.org (8.6.12/8.6.9) with ESMTP id RAA27345 for <hfsig@tapr.org>; Tue, 22 
Aug 1995 17:31:56 -0500 
Received: from frl.orst.edu (FRL.ORST.EDU [128.193.226.10]) by amanda.bus.orst.edu 
(8.6.9/8.6.9) with ESMTP id PAA18932 for <hfsig@tapr.org>; Tue, 22 Aug 1995 
15:31:51 -0700 
Received: from FRL/MERCURY_MAILER by frl.orst.edu (Mercury 1.21); 

22 Aug 95 15:38:36 PST8PDT 
Received: from MERCURY_MAILER by FRL (Mercury 1.21); 22 Aug 95 15:38:27 PST8PDT 
From: "Johan Forrer" <FORRERIJ@frl.orst.edu> 
Organization: Forest Research Lab. Oregon State 
To: hfsig@tapr.org 


Date: Tue, 22 Aug 1995 15:38:26 PST8PDT 
Subject: Re: [HFSIG:543] Re: Robust modems 
Priority: normal 

X-mailer: PMail v3.0 (Ria) 


Message-ID: <196BA07F41@frl.orst.edu> 
Hi Phil, 


Just a question out of curiosity. I gather that the STA for SS does not 
allow for the usage of simultaneous P-N sequences and frequency 

hopping schemes. Without this means of SS, would it be technically possible 
then to solve the near-far problem for amateur communications? 


--Johan 

From karn@qualcomm.com Tue Aug 22 23:07:36 1995 

Received: from servo.qualcomm.com (servo.qualcomm.com [129.46.128.14]) by 
sysi.tapr.org (8.6.12/8.6.9) with ESMTP id XAA30575 for <hfsig@tapr.org>; Tue, 22 
Aug 1995 23:07:33 -0500 

Received: (karn@localhost) by servo.qualcomm.com (8.6.12/QC-BSD-2.5) id VAA16765; 
Tue, 22 Aug 1995 21:07:31 -0700 

Date: Tue, 22 Aug 1995 21:07:31 -0700 

From: Phil Karn <karn@qualcomm. com> 

Message-Id: <199508230407 .VAA16765@servo.qualcomm. com> 

To: hfsig@tapr.org 

In-reply-to: <196BAQ7F41@frl.orst.edu> (FORRERIJ@£r1.orst.edu) 

Subject: Re: [HFSIG:544] Re: Robust modems 


Near-far is a potential problem for all spread spectrum systems, 
regardless of spreading method. Frequency hopping does have the 
advantage of making it easier to deal with hopping collisions through 
coding, but there are techniques applicable to direct sequence as well. 
IS-95 (which is direct sequence) is one example. Power control is 

the key. 


Phil 


From chbrain@dircon.co.uk Wed Aug 23 14:22:05 1995 

Received: from felix.dircon.co.uk (felix.dircon.co.uk [193.128.224.10]) by 

sysi.tapr.org (8.6.12/8.6.9) with SMTP id OAAQ8068 for <hfsig@tapr.org>; Wed, 23 

Aug 1995 14:21:58 -0500 

Received: by felix.dircon.co.uk id AB16802 

(5.67b/IDA-1.5 for <hfsig@tapr.org>); Sat, 12 Aug 1995 06:53:21 +0100 

Message-Id: <199508120553 .AB16802@felix.dircon.co.uk> 

Received: from ad029.pool.dircon.co.uk(193.128.231.29) by amnesiac via smap (V1.3) 
id sma016800; Sat Aug 12 06:53:12 1995 

X-Sender: chbrain@dircon.co.uk 

X-Mailer: Windows Eudora Version 1.4.4 

Mime-Version: 1.0 

Content-Type: text/plain; charset="us-ascii" 

Date: Sat, 12 Aug 1995 05:46:30 +0100 

To: hfsig@tapr.org 

From: chbrain@dircon.co.uk (Charles Brain) 

Subject: Re: [HFSIG:532] Re: Robust modems 


> 
>CCW is a form of coherent demodulation/detection. 
> 
>--Johan, KC7WW 
> 
> 
Hello, 
From my memory the CCW filters I have seen described in the past have used 
Quadrature matched filters which according to my understanding of the book : 


Communication Systems 3/e by Simon Haykin ISBN 0-471-30584-7 published 
by Wiley, are designed for non-coherent reception. 


I guess this means that the phase in CCW is not necessary to know just the 
QRG and the start and end of the integration period ? 


Back to this 8ary FSK modem I am still investigating, well I spoke to a guy at 
Leeds University here in the U.K who works in the H.F radio research dept and 
he advised me that I should be using matched filters for my 8ary modem. 


So this CCW discussion ties in nicely with what I am now looking at. At least 
rectangular pulses are the simplest matched filter to build. 


Regards 
Charles 


(QTH somewhere on the learning curve!) 


"projects don't slip, they just catch up with reality 


Charles Brain (G4GUO) 
Chelmsford, Essex. 

E-mail chbrain@dircon.co.uk 
POTS +44 (0)1245 353221 

FAX +44 (0)1245 275448 


From chbrain@dircon.co.uk Wed Aug 23 15:38:34 1995 

Received: from felix.dircon.co.uk (felix.dircon.co.uk [193.128.224.10]) by 

sysi.tapr.org (8.6.12/8.6.9) with SMTP id PAAQ9292 for <hfsig@tapr.org>; Wed, 23 

Aug 1995 15:38:12 -0500 

Received: by felix.dircon.co.uk id AA17468 

(5.67b/IDA-1.5 for <hfsig@tapr.org>); Wed, 23 Aug 1995 21:37:56 +0100 

Message-Id: <199508232037.AA17468@felix.dircon.co.uk> 

Received: from ad004.pool.dircon.co.uk(193.128.231.4) by amnesiac via smap (V1.3) 
id sma017461; Wed Aug 23 21:37:52 1995 

X-Sender: chbrain@dircon.co.uk 

X-Mailer: Windows Eudora Version 1.4.4 

Mime-Version: 1.0 

Content-Type: text/plain; charset="us-ascii" 

Date: Wed, 23 Aug 1995 20:36:09 +0100 

To: hfsig@tapr.org 

From: chbrain@dircon.co.uk (Charles Brain) 

Subject: Re: [HFSIG:546] Re: Robust modems 


> 
>> 

>>CCW is a form of coherent demodulation/detection. 
>> 

>>--Johan, KC7WW 

>> 


>> 

>Hello, 

> From my memory the CCW filters I have seen described in the past have used 
>Quadrature matched filters which according to my understanding of the book : 


Wow, 
I sent that message about 1 week ago, like a lot of things after re-reading the 
books I regretted sending the message! Still I can't see why it took so long 
to be 
reflected back from the list server. 


I am still playing with the matched filters. Still things have advanced at 

this end 

as I am now using PC-DSP Professional and PC-SIM which allows me to mock up the 
modem before committing it to DSP code. 


It has a few bugs in it but appears good value for money at $200 rather than the 
$2000 + for matlab! 


Hope you all enjoy the DCC I am looking forward to reading the conference notes. 
I have just finished reading the proceedings of HF95 that took place in 

Sweden last 

week. 


Regards Charles 


From sadowskp@usafcrqs.nellis.af.mil Thu Aug 24 11:32:08 1995 
Received: from bncc.nellis.af.mil (bncc.nellis.af.mil [132.58.120.19]) by 
sysi.tapr.org (8.6.12/8.6.9) with SMTP id LAA21071 for <hfsig@tapr.org>; Thu, 24 
Aug 1995 11:31:59 -0500 
Received: from mailgtwy.nellis.a£f.mil by bncc.nellis.af.mil with SMTP 
(1.38.193.4/16.2) id AAQ4993; Thu, 24 Aug 1995 09:31:28 -0700 
Received: by mailgtwy.nellis.af.mil with Microsoft Mail 
id <303C81F2@mailgtwy.nellis.af.mil>; Thu, 24 Aug 95 08:43:14 cdt 
From: "Sadowski,P CPT USAF CRQS/RQEN" <sadowskp@usafcrqs.nellis.af.mil> 
To: hfsig <hfsig@tapr.org> 
Subject: RE: [HFSIG:547] Re: Robust modems 
Date: Thu, 24 Aug 95 08:48:00 cdt 
Message-Id: <303C81F2@mailgtwy.nellis.af.mil> 
Encoding: 20 TEXT 
X-Mailer: Microsoft Mail V3.0 


Please, more info on these two packages 
Thanks in advance 


Al AH6LS 
sadowskp@usafcrqs.nellis.af.mil 

>From: hfsig 

>To: hfsig 

>Subject: [HFSIG:547] Re: Robust modems 


>Date: Wednesday, August 23, 1995 3:50PM 
> PC-DSP Professional and PC-SIM 


> appears good value for money at $200 rather than 
> the $2000 + for matlab! 


> Regards Charles 


From chbrain@dircon.co.uk Thu Aug 24 12:41:57 1995 

Received: from felix.dircon.co.uk (felix.dircon.co.uk [193.128.224.10]) by 

sysi.tapr.org (8.6.12/8.6.9) with SMTP id MAA21986 for <hfsig@tapr.org>; Thu, 24 

Aug 1995 12:41:44 -0500 

Received: by felix.dircon.co.uk id AAQ4264 

(5.67b/IDA-1.5 for <hfsig@tapr.org>); Thu, 24 Aug 1995 18:41:33 +0100 

Message-Id: <199508241741.AA04264@felix.dircon.co.uk> 

Received: from ac035.pool.dircon.co.uk(193.128.230.35) by amnesiac via smap (V1.3) 
id sma004231; Thu Aug 24 18:40:59 1995 

X-Sender: chbrain@dircon.co.uk 

X-Mailer: Windows Eudora Version 1.4.4 

Mime-Version: 1.0 

Content-Type: text/plain; charset="us-ascii" 

Date: Thu, 24 Aug 1995 17:39:07 +0100 

To: hfsig@tapr.org 

From: chbrain@dircon.co.uk (Charles Brain) 

Subject: Re: [HFSIG:548] Re: Robust modems 


> 

>Please, more info on these two packages 
> 

>Thanks in advance 

> 

>Al AH6LS 
>sadowskp@usafcrqs.nellis.af.mil 


>>From: hfsig 

>>To: hfsig 

>>Subject: [HFSIG:547] Re: Robust modems 
>>Date: Wednesday, August 23, 1995 3:50PM 
>> PC-DSP Professional and PC-SIM 


>> appears good value for money at $200 rather than 
>> the $2000 + for matlab! 


>> Regards Charles 
Well here are the facts, I appologise for the advert at the end but I have 
had a number 


of requests for information about the package. 


Hello, 


I hope this is of interest to you! It has some bugs in it but you can 
design filters with it, play with FFTs and 
most other DSP functions. With the PC-SIM I have emulated an 8ary FSK modem. 
I am also going to 
emulate an H.F channel simulator with it, the output can be displayed or 
imported into Excell. I ordered it via 
the internet and it arrived in about 1 week, it fitted in a paddy bag. You 
get the disks and a large manual. 


PC-DSP Professional Edition 


The professional edition of PC-DSP is available from DSP Solutions, and 
provides a significant number of enhancements over the student edition. 
Site licenses are available for educational institutions. In addition, 
students with a valid student ID may upgrade to the professional edition 
at a discounted price. For ordering information, please see the file 
'ORDER.FRM'. For site license information, see the file ‘SITELICE.TXT'. 


Following is a partial list of enhancements in the professional edition 
of PC-DSP: 


x Protected mode support. Works with 286 or better. For most operations, 
discrete sequences can be as long as permitted by available memory and 
disk space. In the student edition, discrete sequences are limited to 
1024 samples. 


x Graphs are customizable in terms of titles, labels, and colors. Support 
is provided for converting graphs to several popular formats including 
postscript, HPGL, and Latex picture formats. This allows professional- 
quality printer plots to be obtained. 


* Increased limits in filter design, analysis, and simulation. In the 
student edition, FIR filters are limited to 55 taps, and IIR filters 
are limited to order 10. The professional edition raises these limits 
to 256 and 50 respectively. 


* Automatic code generation for IIR and FIR filters. Assembly language 
code for designed filters can be automatically generated for Motorola 
DSP56001 and Texas Instruments TMS320C30 processors. In addition, 
standard C code can also be generated. 


* Increased limits for model orders in autoregressive (AR), moving 
average (MA), and autoregressive moving average (ARMA) spectral 
analysis. In the student edition, the model order is limited to 20. 


* Includes the macro compiler. Using the macro compiler, a set of PC-DSP 
commands can be compiled into a macro file which can be executed with 
the 'Run macro' menu choice. This feature makes it possible for the 
user to add new functions to PC-DSP by combining the existing functions 
in a certain way. Also, by using disk file input-output functions, it 
is possible to interface stand-alone executable programs to PC-DSP, and 
make them part of an integrated environment. Full documentation on 


PC-DSP macro language is also included. 


* Includes the dialog compiler. Using the dialog compiler, interactive 
data entry forms can be developed as front ends to PC-DSP macros. 
These data entry forms have the same general characteristics as the data 
entry forms used in PC-DSP user interface shell. Full documentation on 
PC-DSP dialog language is also included. 


*x A number of macros are included covering advanced topics such as 
adaptive filtering and wavelet transforms. Additionally, a macro is 
provided for importing and exporting sound files in WAV format. 


* Source code for reading and writing the binary data files used by 
PC-DSP is provided to aid in the development of child processes 
(external executable programs that are executed from within a macro). 
Languages supported are: C, Pascal, Fortran, and QuickBasic. 


Other Related Products 


This file contains brief descriptions of related products by DSP Solutions. 
For ordering information, please see the file 'ORDER.FRM'. For site 
license information, see the file 'SITELICE.TXT’. 


PC-SIM is a continuous- and discrete-time simulator that is used for 
time-domain simulation of systems described by block diagrams. It was 
designed to be a flexible and open-ended tool to allow simulation of a 
broad range of systems encountered in communications, signal processing, 
and controls. The block diagram under consideration may contain linear 
and nonlinear components. Continuous- and discrete-time components can 
be mixed within the same block diagram through the use of impulse 
samplers coupled with continuous-to-discrete and discrete-to-continuous 
converters, and zero- and first-order hold devices. Multiple samplers 
can be used with different sampling rates and/or non-synchronized timing. 


PC-SIM is fully compatible with PC-DSP in terms of the data file formats 
used. For example, a sequence generated in PC-DSP can be used as input 
to a system to be simulated using PC-SIM. The output signal obtained 
from this simulation can be brought into PC-DSP for FFT analysis. A 
filter (analog or digital) designed using PC-DSP can be used as one block 
in a block diagram to be simulated using PC-SIM. 


A block diagram is described to the program using a very simple script 

language. Simulation models for a wide variety of linear and nonlinear 
component types have been developed for use in systems to be simulated. 
Following is a partial list of available component types: 


Input port (ASCII and PC-DSP files) 
Recorder Cty : =~.) 
Adder 

Multiplier 

Amplifier 

Dead zone 

Comparator 

Comparator w/ dead zone 
Comparator w/ hysteresis 
Limiter 

Limiter w/ dead zone 

Limiter w/ hysteresis 
Compressor (u-law and A-law) 
Expander ( " i tS) 
Full-wave rectifier 

Half-wave rectifier 

Zero-order hold 

First-order hold 

Sampler (Impulse sampling) 
Continuous-to-discrete 
Discrete-to-continuous 
Continuous linear system { G(s) 3 
Discrete linear system { H(z) 3 
Integrator 

Differentiator 

Shifter 

Quantizer 

Multiplexer 

Demultiplexer 

FIR digital filter (from PC-DSP) 
IIR digital filter (from PC-DSP) 
Analog filter (from PC-DSP) 


Sin(x) 

Cos(x) 

Tan(x) 

ArcSin(x) 

ArcCos (x) 

ArcTan(x) 

Sinh(x) 

Cosh(x) 

Tanh(x) 

ArcSinh(x) 
ArcCosh(x) 
ArcTanh(x) 

Exp(x) 

Log (x) 

Log10(x) 

Square 

Square-root 
Reciprocate 

Minimum 

Maximum 

Sine Oscillator 
Cosine Oscillator 
Pulse Oscillator 
Triangular Oscillator 
Unit-Step Generator 
Unit-Impulse Generator 
Gaussian Noise 
Uniform Noise 

Volt. Cont. Oscillator 
Down-Sampler 
Up-Sampler 

Adaptive LMS filter 


In addition, well-commented C language source code can be automatically 
generated for the block diagram described. This allows the development 
of stand-alone executables to simulate particular systems, and can also 
be used for porting a system to run on a DSP processor. 


PC-DSP FOR WINDOWS 


Has the same features as in the PC-DSP professional edition, except it 
works within the Microsoft Windows environment (version 3.1 or higher). 
Tightly integrates with PC-SIM for Windows, but can be used without it 
as well. Available April 1994. 


PC-SIM FOR WINDOWS 


Has the same features as in the DOS version of PC-SIM described above, 
except it works within the Microsoft Windows environment (version 3.1 

or higher). It also allows interactive drawing of the block diagram on 
the screen. Once the block diagram is drawn, the system description file 
is automatically generated, and the simulation is run. Tightly 
integrates with PC-DSP for Windows, but can be used without it as well. 


Available April 1994. 


DSP LIBRARY 


Extensive C language library of signal processing functions in source 
code format. Functions cover a broad range of operations including 
binary file operations, waveform synthesis, elementary signal operations, 
signal statistics, convolution, correlation, FFT analysis, filter design 


and implementation. 


Most of these functions were used in PC-DSP. 


Royalty-free right is granted for the distribution of straight application 
programs (in executable format) developed using these functions. Contact 
DSP Solutions for a list of functions and pricing information. 


DSP Solutions 
P.0.Box 341 
Glen Carbon, IL 62034 


ORDER FORM 


e-mail: pcdsp@minuet.siue.edu 


DspSol@aol.com 


PRODUCT 


PC-DSP Professional 
Edition 


PC-DSP Professional 
Editon (w/ student ID) 


PC-DSP for Windows 
(Available April 1994) 


PC-SIM for DOS 


PC-SIM for DOS 
(w/ student ID) 


PC-SIM for Windows 
(Available April 1994) 


Bundle-1 
PC-DSP Prof. Ed. & 
PC_SIM for DOS 


$59: 


$ 99. 


$ 99. 


$259. 


$129. 


$159. 


PRICE 


. 00 


00 


00 


00 


00 


00 


00 


AMOUNT 


Bundle-2 1 $199.00 $ 
PC-DSP for Windows & 

PC_SIM for Windows 

(Available April 1994) 


Subtotal $ 


Illinois residents must add 6.25 % sales tax $ 


Disk format [3.5"] 5.25" Shipping $ 10.00 
(circle one) 
TOTAL $ (x*) 


(*) Please include a photocopy of your student ID. 
(xx) Personal checks, Visa, MasterCard. 
Purchase orders accepted from academic institutions. 


Name: _ COMPANY? - eee eee 

Address: _ 

City: States. bs. ZEPv co 
CREDIT CARD INFORMATION Circle one: Visa [MasterCard] 

Name on card: Account Number: 


Expiration date: Signature: 


"projects don't slip, they just catch up with reality" 


Charles Brain (G4GUO) 
Chelmsford, Essex. 

E-mail chbrain@dircon.co.uk 
POTS +44 (0)1245 353221 

FAX +44 (0)1245 275448 


From Sivula@ncsmsg01es.ntc.nokia.com Mon Aug 28 10:34:52 1995 
Received: from axl01it.ntc.nokia.com (axl01it.ntc.nokia.com [131.228.118.232]) by 
sysi.tapr.org (8.6.12/8.6.9) with ESMTP id KAAQ0475 for <hfsig@tapr.org>; Mon, 28 
Aug 1995 10:34:37 -0500 
Received: from ntcite01es.ntc.nokia.com (ms-smtp-gw.tele.nokia.fi 
[131.228.138.80]) by axl@1it.ntc.nokia.com (8.6.9/8.6.9) with SMTP id MAA12997 for 
<hfsig@tapr.org>; Mon, 28 Aug 1995 12:21:56 +0300 
Received: by ntciteO01es.ntc.nokia.com with Microsoft Mail 

id <30419971@ntciteO1les.ntc.nokia.com>; Mon, 28 Aug 95 12:24:49 eet 
From: Sivula Timo <Sivula@ncsmsg01es.ntc.nokia.com> 
To: "'HFSIG'" <hfsig@tapr.org> 


Subject: Re: Various comments on the newqpsk 
Date: Mon, 28 Aug 95 12:06:00 eet 

Message-ID: <30419971@ntciteO1les.ntc.nokia.com> 
Encoding: 210 TEXT 

X-Mailer: Microsoft Mail V3.0 


>From: Pawel Jalocha 


>We should take few our latest talks and send them to HFSIG 
>- who will do that ? :-) 


Well, now I did it. Blame me, if you find your texts published ;-) 


>> Do you think that 50 mV could get distorted in the (FT757GX) 

>> mic preamp? 

> 

>I looked at the diagram and there are two transistors with a fancy 
>loopback before it comes to the potentiometer. 

>In principle 50 mV could be distorted there already... not much, 
>but I think a bipolar transistor does show some non-linearity 

>at the 50 mV level. 


Maybe Joni and I shoud try even lower input levels? I think that would at 
least 
sort that alternative out. 


>The MIC socket: On my diagram, there is no AF output on the MIC socket... 
>The audio-in on the read is actually the same as on the MIC socket. 


This is what I remembered, too. I have now found the extra mic plug I had 
so I will solder it in during this week. I will solder the up and down 
switches 

to this plug so that we can test the rig autotuning. This will be very 
interesting! 


>I measured my transmitter passband today... I connected a simple 
>RF-voltmeter to the TRX output. Here are the output amplitudes: 


I plotted this, too. Did you have the mic connected when testing? As the mic 
is 

in parallell with the AFSK input, it influences the response very much. The 
output seems lowpass filtered, and by far not as nice as Jonis' TX. The 
excel 

sheet is in the end of this message as uue. Joni's plot is in the same file 
so you 

can compare the results. 


>The more I think on the problem the more I am conviced that this is 
>a REAL problem in all type of multi-tone modems (including picollo 
systems). 

>I am pretty sure that this is the problem seen now but Joni and Timo. 


>Here are two issues: 

>1. Same as for auto-FEC/Interleave setting: the stations needs IDs 

> known to the TNC and every station should be treated separetely. 
>2. The modem doesn't "see" what on the air directly but through the 

> receover filters, thus the measurement of the carrier's amplitudes 
> will be seriously affected. 


Well, how about adding a learn code in the beginning of every transmission, 
every station could then retune the receiver for each received packet. There 


would be no need for TX recognition as it would be done every time. 


>I like more the idea to measure my transmitter and hardwire the correction. 
>This should fix the thing once and for all. 


This works well with one rig, but what if there is no common characteristic 
for the diffrerent transmitters, as it seems? A software that would take 
the 

results from TXtest and convert them to weights for the different tones in 
NEWQPSK.DAT? That might be a simple solution for the user. 


Here is the new XLS file. 


73, Timo 


begin 644 plot.zip 

M4$LdH#! 10° °° CFE"! 2: @(Li&!< °C EL’ * °° °° 59A415-44EA, 44U="W@5 
MU; 7>>\[[G.2<* WGQD&1 ( (+R2D-=) @HH) $2 (JFJ* H\O (BP@%2DYRO!%' $$FWO 
MJE,115*A/0O° -511\7;5HL; 7042K2>WOQ<I%@] :K] VD] 1\8I5R%UK [YD] CW/F 
MD) !$36'X]LQD_7NM_5I[[;77S!S>V37@X* /;AKQ'3,<90$: .=7J (4T>C2F) ' 
MD! !)4?M89V>G2NX\=?Q+ '4<A'5.271E+'' ,7'V+B@>2%Y(.4° "D1IDA]2° ) (4 
MTQ@! (* RSEO4I&E* (19%5(:I$&O!D,:° FDHI- , @#8.44BD#D@QI.*1,1=P1<!T) 
MxQ_2*$BC(8V!-!;2.$@YD' (A94$: 4#RD?4@&DODAXD (H5. : >. KA\7DOC\ : X60 
MF$(:X=1,KB7=.5)!"U19:°4";HGI=W"X2T WILO?_6+"TI>H##>[ ;%%HEx_\J 
M<Jx ' %ZROOCU=X7%H#NN] TU: : =4#>4WD"923 :XD/R+=/082B: (-M"FVKZM\ERM7 
M! [F8+(7R&\@\U0?GPB@LA! HU, THKI8/ [QCAR1I] *“[,AV;.(L.FGYDS_/2B, 
MOLW+==<\=]%.7U* WOSG2$EG8*xD“Y9GZX7@[EY<LS (\U7M2P. AUN9=U! 9MW!A 
MBxT) +$?>Q8CDA; KH1QPH#C<7R#ZZZ_— .OJQ<'' [_d#3<:->N:_$3?3\H' VGYE\ 
M3<)UIX9P'V1T)T]_44&«: ]CL3+XV-<$5RVW/Y&O4$YE\G7HMDY>_$Z[GP/6= 
MX;S]-F8;&M*K!CX_C6(IMIU!7.F*"5%6.X*DWE$) )QN69I>) ["11B2$) TG[2 
MQ&Q<. J. /HIV=2/<Q7D[7) &A2U;S6.7!-3K6C=* KUQ[**E=0%1>Y<IM9-I>CK 
MAE ; OGY (V"IR#, HYD"5=AO$N"VF=:Y) 58SP] S#B>'R' [6@YDF*3Ex[R3!758, 
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X-Mailer: Microsoft Mail V3.0 


Hello, 


I came home last night at 22 o'clock so I did not have time to make the TX 
test yet. I 
think I'll do it tonight. 


I made the RX test this morning before leaving to the job. I made it in the 
Same manner as 

Pawel: I switched the marker generator on and tuned the rig around the 
marking frequency. 

If I do not recall wrong, the S meter measures the input _voltage_ so that 
one S-unit is 6 dB. 

In order to find the half power bandwidth one needs to find the edges where 
the voltage drops 6dB 

ftom the passband peak, i.e the power drops 3 cB. 


Well, the result was very simple. the -6 dB voltage points were exactly 3,5 
kHz apart. There 

was some ripple in the passband, but it was not more than 1 dB (= the 
thickness of the needle). 

I'll be back with the TX results when I get the tests made. 

My rig is an FT757GX MK I 


73, Timo 
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From: Pawel Jalocha 

To: danie.brynard; Johan Forrer; Timo Sivula; Frode Weierud; Jarkko Vuori; 
Joni 

Subject: Re: Various comments on the newqpsk 

Date: 25. August 1995 23:39 


Hello everybody, 


> First: Should we either move this discussion to the hfsig group, or create 
a 

> new group 

> for DSP56k qpsk testing and reporting? I suggest this, as I am getting fed 
> up with this 

> carbon copying every time :-) 


In principle I could create a simple mailing list on home-gate 
but HFSIG is a better place maybe. 
We should take few our latest talks and send them to HFSIG 

- who will do that ? :-) 


Vv 


How does the headphone output relate to the line output? At least the 
headphone 
> output is quite noisy. 


Vv 


I would expect same amount of noise on the line output. 
The "ideal" solution is to use a resistor divider just before 
the microphone input. 


> Do you think that 50 mV could get distorted in the 
> mic preamp? 


I looked at the diagram and there are two transistors with a fancy 
loopback before it comes to the potentiometer. 

In principle 50 mV could be distorted there already... not much, 
but I think a bipolar transistor does show some non-linearity 


at the 50 mV level. 


This seems like a good idea, the only problem is that as far as I remember 
Joni 

reduced the output power until it could not get less, and it still worked 
ok. The 757 

has quite good dymaics in what comes to setting the TX output. Remember 
that 

> we are only 10 km apart. 


VVVNV Vv 


Your antennas are too good - cut them by half :-) 


The MIC socket: On my diagram, there is no AF output on the MIC socket... 
The audio-in on the read is actually the same as on the MIC socket. 


> Sorry, no. T4 runs on a TheFirmware TNC, and I have to use a KISS emulator 
> (TFKISS) to interface T4 to an non TF TNC. 


I always thought software is so much flexible :-) 


> Why not make this automatic instead? Let the modem collect the number of 

> errorcorrections and then according to some trig-levels switch automaticly 
> to a less complicated FEC and higher speed if the link permits it, and 
vice 


versa. 
You only need to find out how to tell the other modem about the mode 
change... ;-) 


but with 15 tones to choose from that should not be too difficult, I hope. 


Now the modem would autotune and fit the errorcorrecting code according to 
the 
band conditions, what say? 


VV VV VV VV 


In one-to-one QSO this is "easy" but if we want to keep this modem 
compatible with the ideas of packet network the whole issue becomes 
difficult. You are going to send packet to two or three station 

and for every station you may need to use different parameters. 

Thus you need to give every station an ID which is known to the TNC 
(KISS TNC doesn't know anything about callsigns). 

Then, the TNC would need to gather statistics for every ID separately 
and then decide and agree with the other station upon the parameters. 
Phil's new protocol probably does something like this... 


> Here came the Problems. I pressed w once, and the hard disk started 
running. 
> And it did not stop, not until I forced the system down with ctrl-alt del. 


Definetely a wrong behaviour but why I can't say... maybe Jarkko ? 
> What does the S do? What happens when I press w, or what should 


> happen? 
> How does this SPY work? 


When you press "S" the PC sends the request (just the character "s") 

to the DSP to send the "spied data". The programmer (that is me) decides 
what are the "spied data" at the moment. 

In response the DSP sends "P" and then 512 16-bit words. 

This words are being displayed in a form of diagram on the screen. 

They can be for example the FFT values, or just the input samples, 

or samples after a filter - anything: it's up to the programmer. 


When you press "w" the SPY.EXE should write those 512 words onto an ASCII 
file - that's all. Why this simple thing did not work, I don't really know. 


> I will be out of town for the weekend but this test seems to be a good 
one. 

> I'll 

> run it when I get back on monday. Could you make the test soft so that one 
> could give the modulating tone directly as a number? Like 100 (enter) 
would 

> give 100 Hz, 3000 (enter) would give 3 kHz? This would be very useful for 


> other applications as well... A settable sinewave generator on the DSP4! 
Well, you can make it multi-tone, multi-waveform, etc. :-) 
But for now it has to wait... or there is maybe a voluntier 


to take this job ? 


I measured my transmitter passband today... I connected a simple 
RF-voltmeter to the TRX output. Here are the output amplitudes: 


Carrier Amplitude 
number [V] 
dl 14.3 
2 14.2 
3 14.1 
4 13.7 
5 13.0 
6 12:31 
7 11.5 
8 11.2 
9 11.3 
10 11.1 
11 10.7 
12 10.5 
13 10.6 
14 10.5 
15 9.7 


The difference between first and last is about 1.5 which make more 
than 2 in the power level. 


The more I think on the problem the more I am conviced that this is 
a REAL problem in all type of multi-tone modems (including picollo systems). 
I am pretty sure that this is the problem seen now but Joni and Timo. 


What shall we do about it ? I can see two "main" solutions: 

1. Make the transmition so narrow that it fits into "every" transceiver. 
But then your bit rates will be so low... or you will not be able to take 
those _real_ advantages of multi-tone transmitions. And when you make 
the transmition significantly narrower than the SSB passband you get 
additional problems with the AGC of the receiver, the anti-aliasing 
filters, etc. The whole excitement falls apart... 

2. Stay with about 2 kHz bandwidth and let every operator adjust the 

passband 
center and carrier level correction. Thus keep higher bit rate and take 
some advantage of spreading the signal over larger bandwidth. 


> Pawel, excuse me for my mad ideas but... Could this be done? 

> 

> Make one of the preamble tones being in the high end of the pass band. 
Like 

1500 

and, or why not using 3 or more tones. 


The receiving modem, during tune phase, measures the level difference 
between this 

tone and a tone in the "flat" response area. The dummy bits (pre/post data 
or whatever 

they are called) is then used to send the measurement data in the next 
transmission 

back to the other end. 


VV VV VV VV VM 


Here are two issues: 

1. Same as for auto-FEC/Interleave setting: the stations needs IDs 
known to the TNC and every station should be treated separetely. 

2. The modem doesn't "see" what on the air directly but through the 
receover filters, thus the measurement of the carrier's amplitudes 
will be seriously affected. 


I like more the idea to measure my transmitter and hardwire the correction. 
This should fix the thing once and for all. 


How about automating this, too like above? Is it possible? How much 
processing power 

would this correcting need if it would be done "live"? This feature could 
also help against 

selective fading in some cases on HF. 


VV VV WV 


This might be indeed very interresting but is selective fading 
"stable" enough ? I suspect the "notching point" moves all the time... 


Pawel 


From Sivula@ncsmsg01es.ntc.nokia.com Mon Aug 28 10:35:19 1995 

Received: from axl01it.ntc.nokia.com (axlO01it.ntc.nokia.com [131.228.118.232]) by 
sysi.tapr.org (8.6.12/8.6.9) with ESMTP id KAAQ0Q515 for <hfsig@tapr.org>; Mon, 28 
Aug 1995 10:35:08 -0500 

Received: from ntcite01es.ntc.nokia.com (ms-smtp-gw.tele.nokia.fi 


[131.228.138.80]) by axl@1it.ntc.nokia.com (8.6.9/8.6.9) with SMTP id LAA10505 for 
<hfsig@tapr.org>; Mon, 28 Aug 1995 11:33:53 +0300 
Received: by ntciteO01es.ntc.nokia.com with Microsoft Mail 
id <30418E2E@ntciteO1les.ntc.nokia.com>; Mon, 28 Aug 95 11:36:46 eet 
From: Sivula Timo <Sivula@ncsmsg01es.ntc.nokia.com> 
To: "'HFSIG'" <hfsig@tapr.org> 
Subject: Excel plot of Jonis TX 
Date: Mon, 28 Aug 95 11:19:00 eet 
Message-ID: <30418E2E@ntcite01es.ntc.nokia.com> 
Encoding: 160 TEXT 
X-Mailer: Microsoft Mail V3.0 


Hello, 


I plotted Jonis TX response with Excel, so those of you having Excel 5.0 can 
view 

Jonis TX output response. I plotted it against frequency and calculated the 
output 

mean voltage from the mesured power assuming a load of 50+ j0 Ohm 


P=U%2/Z 
U= SQRT(P/50), 


Peak voltage would be U= SQRT(2) * U, if somebody wants to plot that, too. 


There are 4 plots in the file, voltage vs freq, power vs freq and two dB 
plots. 
The dB vs freq is calculated with the lowest measured level as reference -> 


dB = 10 log (P/4,6). I plotted this in two ways in order to make it as easy 
as 

possible to use the results for correcting the modem output. The output 
seems 

quite nice, I think. It is within 1,2 dB within the whole passband. This 
should not 

affect the quality of transmission. Would my loudspeakers do this from 20 to 
20000 Hz 

I would call them dreamware ;-) 


I'll be back with pictures of my own rig when I get the rig measured. 


Please let me know If you would like the plots in EXCEL4 instead? I do not 
have LINUX, 
so this is what I have to offer... 


73, Timo 
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From Sivula@ncsmsg01es.ntc.nokia.com Mon Aug 28 10:35:28 1995 
Received: from axl01it.ntc.nokia.com (axl01it.ntc.nokia.com [131.228.118.232]) by 
sysi.tapr.org (8.6.12/8.6.9) with ESMTP id KAAQ0Q532 for <hfsig@tapr.org>; Mon, 28 
Aug 1995 10:35:18 -0500 
Received: from ntciteO1es.ntc.nokia.com (ms-smtp-gw.tele.nokia.fi 
[131.228.138.80]) by axlO1it.ntc.nokia.com (8.6.9/8.6.9) with SMTP id LAA09778 for 
<hfsig@tapr.org>; Mon, 28 Aug 1995 11:21:48 +0300 
Received: by ntciteO1les.ntc.nokia.com with Microsoft Mail 
id <30418B59@ntciteO1les.ntc.nokia.com>; Mon, 28 Aug 95 11:24:41 eet 
From: Sivula Timo <Sivula@ncsmsg01es.ntc.nokia.com> 
To: "'HFSIG'" <hfsig@tapr.org> 
Subject: Resume of multitone discussion. 
Date: Mon, 28 Aug 95 11:17:00 eet 
Message-ID: <30418B59@ntciteO1es.ntc.nokia.com> 
Encoding: 24 TEXT 
X-Mailer: Microsoft Mail V3.0 


Hello all, 


we (Pawel, Jarkko, Johan, Frode, Joni, Danie and me, Timo) have been 
carrying 

out some practical discussions during the on-air testing of pawels 
multi-tone 

modem. Now when Pawel has made a well working version of the modem the 
discussion has turned more to a discussion covering general aspects of this 
mode. 


I think that it would be very good if everybody on this list could catch up 
with the 

discussion and also join in. I will forward some of the latest mails to the 
hfsig list. 

I hope that the guys in the test-group would also move the discussion to 
hfsig, 

because I personally am getting fed-up with the carbon copying ;-) 


If you get fed up with this DSP4 related stuff, don't hesitate to ask us to 
get back 
in to the silence ;-) 


73, Timo OH6KK/OH2LVZ 
From Sivula@ncsmsg01es.ntc.nokia.com Mon Aug 28 10:35:35 1995 
Received: from axl01it.ntc.nokia.com (axl01it.ntc.nokia.com [131.228.118.232]) by 
sysi.tapr.org (8.6.12/8.6.9) with ESMTP id KAAQ0Q547 for <hfsig@tapr.org>; Mon, 28 
Aug 1995 10:35:27 -0500 
Received: from ntcite01es.ntc.nokia.com (ms-smtp-gw.tele.nokia.fi 
[131.228.138.80]) by axl@1it.ntc.nokia.com (8.6.9/8.6.9) with SMTP id LAA09879 for 
<hfsig@tapr.org>; Mon, 28 Aug 1995 11:23:59 +0300 
Received: by ntciteO01es.ntc.nokia.com with Microsoft Mail 
id <30418BDD@ntciteO1les.ntc.nokia.com>; Mon, 28 Aug 95 11:26:53 eet 
From: Sivula Timo <Sivula@ncsmsg01es.ntc.nokia.com> 
To: "'HFSIG'" <hfsig@tapr.org> 
Subject: FW: A test to resolve passband problems 
Date: Mon, 28 Aug 95 11:17:00 eet 
Message-ID: <30418BDD@ntciteO1les.ntc.nokia.com> 
Encoding: 36 TEXT 
X-Mailer: Microsoft Mail V3.0 


From: Pawel Jalocha 

To: Joni; Timo Sivula 

Subject: A test to resolve passband problems 
Date: 24. August 1995 13:41 


To resolve what is the problem with the amount of errors on Timo's side 
I suggest the following experiment: 


Joni would send regular beacons (a rather long ones - 100-200 bytes). 


Timo will do the following: 
- compile the source with SPY=1 and SPY_RxCrossedIQ=1 
- disconnect the PTT and MIC lines from the tranceiver 
because with SPY=1 the modem transmits random data packets. 
- load the .LOD file into the his DSPCARD4 
- start the SPY.EXE (supplied with the DSPCARD4 tools) like this: 
spy -p2 (-p2 means the DSPCARD4 is on the COM2) 
- press "s" when Joni's beacon comes and the red LED flickers. 
After a moment Timo will get some funny data displayed on his screen. 
- press "w" to save this data into a log.dat file. 
- e-mail this file to me ! :-) 


The data there will be the real and imaginary parts of the differential 
phase decoder output for every carrier. The plot will have the periodicity 
of 30 because there are 15 carriers and 2 values/carrier. 

You can see there how much the carrier amplitudes vary and how clean 

the output is: for no-noise output the imaginary part (the second number) 
should be zero. I hope to find out this way whether the problem concentrates 
around the edge carriers or maybe it is spread all over the band. 


Pawel 


From Sivula@ncsmsg01es.ntc.nokia.com Mon Aug 28 10:35:44 1995 
Received: from axl01it.ntc.nokia.com (axl01it.ntc.nokia.com [131.228.118.232]) by 
sysi.tapr.org (8.6.12/8.6.9) with ESMTP id KAAQQ566 for <hfsig@tapr.org>; Mon, 28 
Aug 1995 10:35:37 -0500 
Received: from ntciteO1es.ntc.nokia.com (ms-smtp-gw.tele.nokia.fi 
[131.228.138.80]) by axl@1it.ntc.nokia.com (8.6.9/8.6.9) with SMTP id LAA10083 for 
<hfsig@tapr.org>; Mon, 28 Aug 1995 11:26:20 +0300 
Received: by ntciteO01es.ntc.nokia.com with Microsoft Mail 
id <30418C69@ntciteO1les.ntc.nokia.com>; Mon, 28 Aug 95 11:29:13 eet 
From: Sivula Timo <Sivula@ncsmsg01es.ntc.nokia.com> 
To: "'HFSIG'" <hfsig@tapr.org> 
Subject: FW: A piece of my discussion with Joni 
Date: Mon, 28 Aug 95 11:18:00 eet 
Message-ID: <30418C69@ntciteO1es.ntc.nokia.com> 
Encoding: 94 TEXT 
X-Mailer: Microsoft Mail V3.0 


From: Pawel Jalocha 

To: Danie Brynard; Frode Weierud; Timo Sivula; Johan Forrer 
Subject: A piece of my discussion with Joni 

Date: 24. August 1995 23:09 


Just a piece of my discussion with Joni, I thought it could be interresting. 


> > Does your NOS behave the same ? 
SS 
> Sorry to say but yes. We must do first some coding to get this one work. 


Maybe at least Timo's T4 can issue KISS commands ? 
I found a partial way around this problem in JONS - you type: 


comm tne "\300\10\1\300" (this command sends a given string to a given 
interface) 


In this example I send the following characters: 
COhex, 8, 1, COhex and the comm adds CR (13) by itself. 


COhex is the "new packet" flag in KISS protocol so after all I send a 
complete 
packet saying: set parameter 8 to value 1. 


The problems are: 

1. I cannot send a zero because a zero byte is the end-of-string marker. 
Thus I cannot set the FEC nor the Interleave to zero ! 

2. The "comm" adds the CR by itself thus infact I start a new packet 
and put one byte into it... this makes problem sometimes and the first 
good packet which follows is not accepted. 


> Yep, but it works well with FEC 3 and we tested this spy thing you 
> tols us to do, Timo had problems with his spy and it made 8 MB files on 
> hid HD ;-)... user error who knows ;-) 


This is very funny... for me the SPY makes a file of 512 lines and there is 
one decimal number in every line. I never had problems with that. 


You could try to set transceivers to some low power (5-10W) with FEC=3 
and then ask somebody to put a dead carrier on the channel 


> 
> 
> - the packets should still be received ! 
> 


VV VV WV 


Yes this test we MUST do ... very very intresting one. 


The result maybe mixed because already some carriers seems 
to be very weak but you should try. 


Then, if you set large Interleave and FEC=3 ask somebody to make 
burst noise or make it yourself with a bad lamp switch :-) 
The packets should still come through... 


With FEC=3 and Interleave=16 you can withstand 3*16/2 = 24 symbol 

burst error - this makes 24/83.33 = about 0.3 second. 

A good example of a burst errors is when you hear a distant lighting storm 
- the static crashes can blank any signal for a fraction of second 
- well, sometimes for a few seconds :-) 


> My results: with normal usb and width/shift knobs as they were during 
> fec 3 testings i got results between 2.1 khz and 2.3 khz !!! 
> I know that with width/shift knobs i can change this a little. 


For me the points where the S-meter falls down by 1S are: 
29.999.6 and 29.997.2 thus I get 2.4 kHz at -6dB. 

The passband center is at 29.998.4 which corresponds to the audio 
frequency of 1600 Hz (if the tranceiver is aligned right). 


I have placed the modem's center carrier on 1625 Hz - so for me 
it all right, for you... I don't know :-) 


The modem in principle needs at least 15 carriers * 125 Hz/carrier = 1875 
Hz. 

Because the symbol shape is rather short it spreads a bit more over 

the frequency so it would be better to have about 2100 Hz. 

The problem is that you don't know where this 2.1 kHz is located in your 
radio (where is its center). In the receiver you can adjust the band's 
center but for the transmitter you probably cannot. 

On the diagram of the FT757 I can see that during transmit, the IF shift 
is forced to a certain voltage regardless of the IF shift knob setting. 
Would be nice to have a tool to measu the transmitter response and place 
the signal's spectrum at the best position. 


I could let the DSP send a series of tone of different frequency 
and you could watch the power-meter for amplitude changes. Then 
you could find out the passband edges and the center ? 


This sounds like a good test to let us understand where is the problem. 


By the way, you can try the LSB mode - I am sure the response is going 
to be different :-) and the result may come out better. 


Pawel 


From Sivula@ncsmsg01es.ntc.nokia.com Mon Aug 28 10:35:50 1995 
Received: from axl01it.ntc.nokia.com (axl01it.ntc.nokia.com [131.228.118.232]) by 
sysi.tapr.org (8.6.12/8.6.9) with ESMTP id KAAQ0575 for <hfsig@tapr.org>; Mon, 28 
Aug 1995 10:35:43 -0500 
Received: from ntcite01es.ntc.nokia.com (ms-smtp-gw.tele.nokia.fi 
[131.228.138.80]) by axl@1it.ntc.nokia.com (8.6.9/8.6.9) with SMTP id LAA09824 for 
<hfsig@tapr.org>; Mon, 28 Aug 1995 11:22:56 +0300 
Received: by ntciteO01es.ntc.nokia.com with Microsoft Mail 
id <30418B9E@ntciteO1les.ntc.nokia.com>; Mon, 28 Aug 95 11:25:50 eet 
From: Sivula Timo <Sivula@ncsmsg01es.ntc.nokia.com> 
To: "'HFSIG'" <hfsig@tapr.org> 
Subject: FW: Various comments on the newqpsk 
Date: Mon, 28 Aug 95 11:17:00 eet 
Message-ID: <30418B9E@ntciteO1es.ntc.nokia.com> 
Encoding: 98 TEXT 
X-Mailer: Microsoft Mail V3.0 


From: Pawel Jalocha 

To: Joni Becklund; Timo Sivula; Danie Brynard; Frode Weierud; Johan Forrer; 
Jarkko Vuori 

Subject: Various comments on the newqpsk 

Date: 23. August 1995 21:57 


Hi to all ! 


Joni just told he made some successfull tests with Timo ! 

He asked some questions and I thought the answer would be 
interresting to all people involved... 

I hope Joni doesn't mind that I have included his words here... 


>Modem works best when fec mode 3 is active. We tested it without 
>fec and it worked with about 30-40% repeats so wi think that £t757 
>filters are too narrow for it anyway... 


FEC=3 has best correcting capabilities, so this is no suprise. 

The reason for many errors with no FEC I can see two: 

1. the filters are too narrow so the carriers on the edge get 
many symbols corrupted. 

2. The spikes of the modem's waveform are cut off by the transmitter 
and this makes lot of errors on all carriers. 
The only cure for now is to lower the driving level - this lowers 
the output power too... 


>Intresting point is that fec mode 1 did't work at all.. dcd flickers etc... 


This I don't understand at all, please see if the modem works with FEC=1 
in loopback. I could have screwed up something with FEC=1 in the recent 
version. In principle if FEC=0 works then FEC=1 should work too 

and much better. 


>With fec 3 we had nice qso and we down/uploaded some files without 
>any repeats. Signal levels during test were 59+ - 57 .... 


You didn't do very high speed but it's a great thing ! 
In next tests you could try to lower the power and see how much 
you can go down before you start missing the packets. 


>We tested modem also while txjam was 4 and txtunelen/txsynclen 16.. 
> 
>It worked fine like this also. 


I understand you tried to lower these numbers for lower overhead 
due to preambles and post-ambles. 
Did you modify the corresponding receiver parameters like RxMinTune ? 


>Timo has some problems with his receive, he said that dcd flickers 
>when packets are received... Mine worked like this: at the beginning 
>the dcd is steady the it goes off and comes on again and says on 

>until hole packet/s are gone. So i think this dcd-off state is when 
>txtune/sync off and packet starts ?? Im not sure but with short packets 
>this point is abt half on hole packet lenght. 


I should explain here the details... when the receiver detects 

the tune preamble it turns the LED on. Then, it keeps the LED on 

while it receives the symbol-sync preamble. Now, when it goes into 

data more the LED is switched on or off depending on the FEC decoder 
errors. 

Note that just after the receiver switches to the data mode there are 
only the four sync. tones active thus the received data is mostly garbage 
thus the FEC finds error and the LED is off. Then, when all 15 tones come up 
there is still some time left before the interleaver fills up. Only after 
some time (propotional to the "Interleave") the FEC decoder gets a 
reasonable 

data so the LED comes up again. 


I would say Joni's LED behaved exactly as it should and no flickering 

ment almost perfect data. Timo's red was flickering - thus this was 

either his received (audio level too high or too low) or Joni's transmitter 
drive level or something in the filters or the frequency error to high ? 

IF shift maybe on Timo's side ? 


Timo could try to use the AGC - I think is pretty safe if you don't want 
to play with setting the gain right. Joni could try to lower the transmitter 


level. 


>So I would say that is WORKS !!! but I must say that it would be instesting 


>to measure £t757 and its receiver on sbb... I mean how big differencies 
>there are in signal levels when testing hole sbb bandwith. 


>From what I see on my FT757 the ssb filter passes the audio from 200-300 Hz 
to 2700-2800 Hz at -6dB. I measure this by turning the calibrator on and 
tuning between say 29100 and 29103 kHz and observing the S-meter. 

This is not bad at all... but, the audio filters after the SSB demodulator 
make a strong dumping of high frequencies, the band 500-1000 Hz is passed 
well but the 2700-2800 Hz band is attenuated by about 3 times (9dB). 


>ps. maybe we could to some testing to africa later ;-) 
We will all hold our breaths :-) 
Pawel 


From Sivula@ncsmsg01es.ntc.nokia.com Mon Aug 28 10:35:59 1995 
Received: from axl01it.ntc.nokia.com (axl01it.ntc.nokia.com [131.228.118.232]) by 
sysi.tapr.org (8.6.12/8.6.9) with ESMTP id KAAQ0Q589 for <hfsig@tapr.org>; Mon, 28 
Aug 1995 10:35:51 -0500 
Received: from ntcite01es.ntc.nokia.com (ms-smtp-gw.tele.nokia.fi 
[131.228.138.80]) by axlO1it.ntc.nokia.com (8.6.9/8.6.9) with SMTP id LAA09980 for 
<hfsig@tapr.org>; Mon, 28 Aug 1995 11:25:05 +0300 
Received: by ntciteO01es.ntc.nokia.com with Microsoft Mail 
id <30418C1E@ntciteO1les.ntc.nokia.com>; Mon, 28 Aug 95 11:27:58 eet 
From: Sivula Timo <Sivula@ncsmsg01es.ntc.nokia.com> 
To: "'HFSIG'" <hfsig@tapr.org> 
Subject: FW: Various comments on the newqpsk 
Date: Mon, 28 Aug 95 11:18:00 eet 
Message-ID: <30418C1E@ntcite01es.ntc.nokia.com> 
Encoding: 119 TEXT 
X-Mailer: Microsoft Mail V3.0 


From: Pawel Jalocha 

To: Timo Sivula <Timo.Sivula@ntc.nokia.com> Danie Brynard; Frode Weierud; 
Pawel Jalocha; Jarkko Vuori; Joni; Johan Forrer 

Subject: Re: Various comments on the newqpsk 

Date: 24. August 1995 10:00 


Hello, 


> We tried reducing the mic gain at Jonis end without any change. We used 

> txattenuate 20 dB. I noticed that the best recption I got when Jonis TX 

was 

> on 

> very low power, he had his microphone disconnected and I had the RF gain 

> attenuating 

> so that there was very little noise coming trough and the level low. What 
is 

> the level coming 


> out of the modem? Could it be possible that the signal gets distorted at 
the 

> TX 

> already _before_ the mic gain potentiometer? 


I didn't measure the modem's output level but it should be around 500 mV 
and the 20.0 dB attenuation would divide this by 10 thus making 50 mV. 

If you think it is too much just put more attenuation... 40 dB = 100 times 
=> 5 mV output. The thing is I don't know how much noise is present 

on the CODEC's output... 


> I tested both with the AGC on, and without it. No big difference. It is 

> clear that there 

> were errors in the signal coming trough as the red led flickered when 
Jonis 

> modem 

transmitted. The QSO was perfect however, because the fec corrects these 
errors. 

In real HF conditions I do not think that this modem would work very well. 
I agree with Joni in that one propable problem is the receiver bandwidth. 


tried 
playing around with the shift and width knobs but they did not help the 
situation at all. 


VV VHWV VV Vv 


The width knob ? You mean maybe the notch knob inside the shift knob ? 
This one should be switched off - otherwise it notches out a piece 
of the passband. 


To judge the modem performance you could make a comparison test: 
With FEC=3 see at which power you can reliably communicate. 

Then try to make a packet QSO with a standard 1200 bps modem 
(maybe you need to switch to FM...) and see again how much 
power you need now ? 


> The only thing that made any difference was using the RF gain to attenuate 
> the incoming 

> signal, this improved the LED behavior. This would imply some form of AF 

> level related 

> problem. 


Wasn't the noise blanker turned on maybe ? It could clip and blank pieces 
of the signal. I would try both slow and fast AGC setting too. 


> FECL seems not to be working very well, I have not made any loopback tests 
> yet. I think 

> that the error correcting is not powerful enough to correct the errors 
that 

> FEC3 manages 

to correct. I could copy a few of Jonis packets but he did not copy 
anything. There might 

also be something wrong with the algorythm, too. Have you made loopback 
tests with it, Pawel? 


VV VV 


Yes, I have done tests yesterday and FEC=1 makes a much better copy 
than FEC=0 in the presence of noise. I agree that FEC1 isn't as good 
as FEC3 but what I don't understand is why FEC1 is worse than FECO ? 


> The modem worked great with FEC3, the qso was like any packet QSO, not 

> better not 

> worse. I would say that the improvement to the earlier versions is huge. 

> Congrats Pawel, 

> you are coming very close to it now! It might need be wise to maybe remove 
> one carrier? 

> This would squeeze the thing a little and it might fit better into the 
used 

> bandwidth? 


If I remove one carrier, we can only work with FEC=0... 
I see if I could easily remove maybe two "edge" carriers. 


The other reason for our problems can be that my front FIR filter is 

too narrow... this would cause problems when the tranceivers are miss-tuned 
by too much. Please try the next time to change slighly the frequency 

and see if this improves the error rate. 


If you connect two LEDs to the UP/DOWN outputs (next to the PTT output) 
you will notice if the modem is misstuned by more than 20 Hz and in 
which direction. Better yet, connect these lines to the up/down pins 
of the microphone socket of the FT757 - and the DSPCARD4 will 

should correct the error automatically at the end of every transmition. 
This have never been tried however :-) 


>>ps. maybe we could to some testing to africa later ;-) 


I've hear rumours of this. Could somebody inform me a little, too? I would 
very much like to join these tests. 


Just make an appointment with Danie ! 


A question to Timo: with T4 can you give an arbitrary KISS command ? 
I am working on switching the FEC and Interleave via a KISS command 
so you can do it on-line during a connect as to quickly find the best 
setting. For eexample I would made FEC switchable with parameter 20 
and the Intnerleave with parameter 21. Other things (TxAttenuate for 
example) could be made switchable too. 


Pawel 


From Sivula@ncsmsg01es.ntc.nokia.com Mon Aug 28 10:36:09 1995 

Received: from axl01it.ntc.nokia.com (axl01it.ntc.nokia.com [131.228.118.232]) by 
sysi.tapr.org (8.6.12/8.6.9) with ESMTP id KAAQQ603 for <hfsig@tapr.org>; Mon, 28 
Aug 1995 10:36:01 -0500 

Received: from ntciteO1es.ntc.nokia.com (ms-smtp-gw.tele.nokia.fi 
[131.228.138.80]) by axlO1it.ntc.nokia.com (8.6.9/8.6.9) with SMTP id LAA10144 for 
<hfsig@tapr.org>; Mon, 28 Aug 1995 11:27:27 +0300 


Received: by ntciteO01es.ntc.nokia.com with Microsoft Mail 
id <30418CAD@ntciteO1es.ntc.nokia.com>; Mon, 28 Aug 95 11:30:21 eet 
From: Sivula Timo <Sivula@ncsmsg01es.ntc.nokia.com> 
To: "'HFSIG'" <hfsig@tapr.org> 
Subject: FW: Program to test transmitter passband 
Date: Mon, 28 Aug 95 11:18:00 eet 
Message-ID: <30418CAD@ntciteO1es.ntc.nokia.com> 
Encoding: 57 TEXT, 62 UUENCODE 
X-Mailer: Microsoft Mail V3.0 
X-MS-Attachment: TXTEST.ZIP 2505 08-25-1995 02:15 


From: Pawel Jalocha 

To: Danie Brynard; Joni Becklund; Timo Sivula; Johan Forrer; Frode Weierud 
Subject: Program to test transmitter passband 

Date: 25. August 1995 0:48 


[[ TXTEST.ZIP : 2398 in TXTEST.ZIP ]] 
So, I have written a simple program to "measure" the passband of your 
tranceiver's transmitter. How to use it: 


- Compile the source and load the .LOD into the DSPCARD4/EVM56K. 

You will hear a tone in your headphones. 

- Start any terminal emulator, set it to 19200 bps, 8-bits, no parity 
and the serial port which is connected to the DSP's SCI. 

With <,>,[,],%,% you can change the tone's frequency and you can see 
it's current frequency on the monitor. 

- Connect the DSPCARD/EVM56K to the transceiver (PTT and MIC lines). 
Push "p" - and the DSPCARD4 will key the transmitter (dummy load !). 
Set a low power level (5-10W) and the meter into such mode so you can 
observe the RF output power. 

Pushing "p" once more switches the transmitter off. 

- Now you can vary the tone around and see how the output power changes. 
Notice the edges where the power quickly drops out and notice too 
how the passband looks like, whether it is flat o sloppy. 


My passband begins at about 400 Hz and looks flat up to 1000 Hz, 

then if falls down slowly but systematically. The upper edge apears 

at about 2700-2800 Hz. 

I must say I don't like this... for the receiver's non-flat passband 

I didn't care so much, but if the transmitter makes the same, the upper 
carriers are going to be much weaker on the air than the lower ones 

and this will truly affect the error rates. What can we do about it ? 
For now I can see only one solution: pre-amplify some carriers before 
transmition (a very easy thing to do). 


I suggest that now everybody should measure his transmitter 
and put down the output levels for various frequencies 
- ideally for every carrier being used by the modem. 
If this is done we can put the numbers into the newqpsk.bas 
as to generate a set ot tones which would have equal amplitudes 


at the antenna socket. 
Pawel 


section 1 of uuencode 5.02 of file txtest.zip by R.E.M. 


This uuencoded part of the message containing the file txtest.zip has been 
decoded and converted into an attachment. 


sum -x/size 10413/3479 section (from "begin" to "end") 
sum -x/size 38585/2505 entire input file 


The following binary file has been uuencoded to ensure successful 
transmission. Use UUDECODE to extract. 


begin 600 TXTEST.ZIP 

MA$SLHE!!0°°@' (,, $&1]>H4">4PD**)@@***** °° 5%A415-44+D%33>5:_U?; 
M.!+_47B/_V$>[3V@F&* [O$N@W%) (KKD-) OOL+OON [O%D6TES ; <F59)+LW?WO 
M) \EV+.<+I3WVI_-[-+8T\]%H9B3-C'K<Z?; :+;BINVW?W; . ;BX=Z'"$A° 4=$ 
M$D9;X._+$5° !G&7#34+5[1T<'!ZVO' @BLIC$¥R1I$5S"I, O<)%;=DD&$US="J.H= 
M510X* I1%A$E*A* @OC13 (SKAM\*" /OCB&OZ&BA2/DP$W_Z) 7K<T=1X-T$D; Q% 
MHEWG74A& (I8OVR. "AQ: . LD<8.B/3HD8<_4#, <- ] 28YF4#9ODO(&XT /%OKZFE_GGS 
M4H_""EF2DACO2I) @" ! DS$E$T ]dHEM7RX /4#G\ $P%\ R<*%ZCEUX?PH7 -_WSLAN+ 
M_?4U6/$<>YK.H+BNKQ%0OD%9QA” , 0!02=Z [H-5W?<3LZ4PFF&) #: LNM=7?3,H 
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From: Sivula Timo 

To: Pawel Jalocha; danie.brynard; Frode Weierud; Jarkko Vuori; Joni; Johan 
Forrer 

Subject: Re: Various comments on the newqpsk 

Date: 25. August 1995 9:35 


Hello! 


First: Should we either move this discussion to the hfsig group, or create a 
new group 

for DSP56k qpsk testing and reporting? I suggest this, as I am getting fed 
up with this 

carbon copying every time :-) 


I will comment the latest three messages from Pawel in this one and only 
message, as I think 

it is easier and the topic is of interest to all involved here. The message 
is quite long, I am 

afraid. Maybe I should have kept it in three parts anyway... I have some 
really weird ideas presented in the end of the message... 


>Subject: Re: Various comments on the newqpsk 
>Date: 24. August 1995 10:00 


>If you think it is too much just put more attenuation... 40 dB = 100 times 
>=> 5 mV output. The thing is I don't know how much noise is present 
>on the CODEC's output... 


How does the headphone output relate to the line output? At least the 
headphone 

output is quite noisy. Do you think that 50 mV could get distorted in the 
mic preamp? 


>The width knob ? You mean maybe the notch knob inside the shift knob ? 


Both Joni and I are using the FT757 GX MK I and it does not have a notch, 
instead 
there is a shift function where the MK II has a notch. 


>To judge the modem performance you could make a comparison test: 
>With FEC=3 see at which power you can reliably communicate. 
>Then try to make a packet QSO with a standard 1200 bps modem 
>(maybe you need to switch to FM...) and see again how much 
>power you need now ? 


This seems like a good idea, the only problem is that as far as I remember 
Joni 

reduced the output power until it could not get less, and it still worked 
ok. The 757 

has quite good dymaics in what comes to setting the TX output. Remember that 
we are only 10 km apart. 


>Wasn't the noise blanker turned on maybe ? It could clip and blank pieces 
>of the signal. I would try both slow and fast AGC setting too. 


No noiseblanker was used, and I tested both slow and fast AGC. 
>Yes, I have done tests yesterday and FEC=1 makes a much better copy 


>than FEC=0 in the presence of noise. I agree that FEC1 isn't as good 
>as FEC3 but what I don't understand is why FEC1 is worse than FECO ? 


This is what I suspected. We did not do any long tests with FEC=1, so our 
report 

is not 100% valid. I guess that it simply did not manage all errors that 
were on 

the signal. FEC=3 could. Or we didn't tune it long enough. 


>If I remove one carrier, we can only work with FEC=0... 
>I see if I could easily remove maybe two "edge" carriers. 


Too bad. 


>The other reason for our problems can be that my front FIR filter is 

>too narrow... this would cause problems when the tranceivers are miss-tuned 
>by too much. Please try the next time to change slighly the frequency 

>and see if this improves the error rate. 


We did tune a lot, but there was no big difference in the result. 


>which direction. Better yet, connect these lines to the up/down pins 
>of the microphone socket of the FT757 - and the DSPCARD4 will 

>should correct the error automatically at the end of every transmition. 
>This have never been tried however :-) 


I think this is the next step we will test. I'll have to find out a neat way 
to 

connect the up & dwn buttons to the rear of the rig, so that I will not have 
to 

connect it to the mic. An other solution would be using a mic plug to feed 
the AF in to the rig, not the AFSK/PATCH socket in the back of the rig. This 


way I could connect the DSP4 directly to the mic socket. I even have a spare 
microphone plug that I could solder in. Hmmm, I think I'll try this. Does 
anybody 

know if there is any AF out in the mic socket of the 757, so that I could 
connect 

all lines to the one and same plug? 


>A question to Timo: with T4 can you give an arbitrary KISS command ? 


Sorry, no. T4 runs on a TheFirmware TNC, and I have to use a KISS emulator 
(TFKISS) to interface T4 to an non TF TNC. 


>I am working on switching the FEC and Interleave via a KISS command 
>so you can do it on-line during a connect as to quickly find the best 
>setting. For eexample I would made FEC switchable with parameter 20 
>and the Intnerleave with parameter 21. Other things (TxAttenuate for 
>example) could be made switchable too. 


Why not make this automatic instead? Let the modem collect the number of 
errorcorrections and then according to some trig-levels switch automaticly 
to a less complicated FEC and higher speed if the link permits it, and vice 
versa. 


You only need to find out how to tell the other modem about the mode 
change... ;-) 
but with 15 tones to choose from that should not be too difficult, I hope. 


Now the modem would autotune and fit the errorcorrecting code according to 
the 
band conditions, what say? 


Now to the second mail: 


>Just a piece of my discussion with Joni, I thought it could be 
interresting. 


>> Yep, but it works well with FEC 3 and we tested this spy thing you 
>> tols us to do, Timo had problems with his spy and it made 8 MB files on 


>> hid HD ;-)... user error who knows ;-) 
> 
>This is very funny... for me the SPY makes a file of 512 lines and there 


>one decimal number in every line. I never had problems with that. 
Hey guys, tell me how to use this spy-thing! Here are the original notes 
Pawel and my comments: 


>Timo will do the following: 

>- compile the source with SPY=1 and SPY_RxCrossedIQ=1 

>- disconnect the PTT and MIC lines from the tranceiver 

> because with SPY=1 the modem transmits random data packets. 
>- load the .LOD file into the his DSPCARD4 


All the previous went fine. 


>- start the SPY.EXE (supplied with the DSPCARD4 tools) like this: 
> spy -p2 (-p2 means the DSPCARD4 is on the COM2) 


I have my DSP on COM 1 so I used SPY -pi1, and I tested also just SPY. 
The program started ok. 


>- press "s" when Joni's beacon comes and the red LED flickers. 


I pressed s once and there was indeed a funny colored figure on the screen 


> After a moment Timo will get some funny data displayed on his screen. 
>- press "w" to save this data into a log.dat file. 


is 


by 


Here came the Problems. I pressed w once, and the hard disk started running. 


And it did not stop, not until I forced the system down with ctrl-alt del. 
When I then 


checked what I had made there was a 9 MB file calle log.dat. This I can not 


send 

to you ;-) What does the S do? What happens when I press w, or what should 
happen? 

How does this SPY work? 


>By the way, you can try the LSB mode - I am sure the response is going 
>to be different :-) and the result may come out better. 


This we have not tested with the latest version. 


>So, I have written a simple program to "measure" the passband of your 
>tranceiver's transmitter. How to use it: 


I will be out of town for the weekend but this test seems to be a good one. 
I'll 

run it when I get back on monday. Could you make the test soft so that one 
could give the modulating tone directly as a number? Like 100 (enter) would 
give 100 Hz, 3000 (enter) would give 3 kHz? This would be very useful for 
other applications as well... A settable sinewave generator on the DSP4! 


>My passband begins at about 400 Hz and looks flat up to 1000 Hz, 


>I must say I don't like this... for the receiver's non-flat passband 

>I didn't care so much, but if the transmitter makes the same, the upper 
>carriers are going to be much weaker on the air than the lower ones 
>and this will truly affect the error rates. What can we do about it ? 


Pawel, excuse me for my mad ideas but... Could this be done? 


Make one of the preamble tones being in the high end of the pass band. Like 
1500 
and, or why not using 3 or more tones. 


The receiving modem, during tune phase, measures the level difference 
between this 

tone and a tone in the "flat" response area. The dummy bits (pre/post data 
or whatever 

they are called) is then used to send the measurement data in the next 
transmission 

back to the other end. 


The modems would monitor the upper end of the AF spectrum all the time and 
adjust the 

levels according to what it gets form the other end. I guess that 
quantizizing with 4 bits 

might be enough? One could assume that the passband is flat to 1 kHz, and 
quantizize the 

difference between this "flat" level and the high end level. If one asumes a 
linear decay 

of the response from 1 kHz upwards only the highest tone has to be 
monitored, anda 

linear correction from 1 kHz to the upper frequency would be calculated. If 
the linear 

assumption is too inaccurate, why not measure more tones? 


>For now I can see only one solution: pre-amplify some carriers before 
>transmition (a very easy thing to do). 


How about automating this, too like above? Is it possible? How much 
processing power 

would this correcting need if it would be done "live"? This feature could 
also help against 

selective fading in some cases on HF. The correction could of course either 
be done at the 

receiver or the transmitter end, or why not both? I would prefer the TX side 
as this would 

increase the S/N of the higher tones. 


>I suggest that now everybody should measure his transmitter 
>and put down the output levels for various frequencies 


Yep, and if a common knee point (1 kHz?) is found it could be used 
as the other end of the linear correction... :-) 


What do you think? 


73, Timo 

From karn@qualcomm.com Mon Aug 28 18:45:09 1995 

Received: from servo.qualcomm.com (servo.qualcomm.com [129.46.128.14]) by 
sysi.tapr.org (8.6.12/8.6.9) with ESMTP id SAAQ7044 for <hfsig@tapr.org>; Mon, 28 
Aug 1995 18:45:02 -0500 

Received: (karn@localhost) by servo.qualcomm.com (8.6.12/QC-BSD-2.5.1) id 
PAA22381; Mon, 28 Aug 1995 15:55:55 -0700 

Date: Mon, 28 Aug 1995 15:55:55 -0700 

From: Phil Karn <karn@qualcomm. com> 

Message-Id: <199508282255 .PAA22381@servo.qualcomm. com> 

To: hfsig@tapr.org 

Cc: antonio@qualcomm.com 

Subject: FFT progress 


I thought the group might be interested in my progress on FFT code for 
the Intel machines. Franklin Antonio N6NKF and I are in a little 
friendly competition to see who can do the fastest FFT on a 90 Mhz 
Pentium. He's using Windows and the Watcom C compiler while I'm using 
BSDI 2.0 and GCC 2.6.3. 


So far Franklin has been a little ahead of me. From looking at the asm 
code his compiler produces, it looks like it knows how to optimize for 
the Pentium, unlike my version of GCC. 


So I've been writing some of the butterflies by hand in assembler with 
careful attention given to keeping the floating point pipeline full 
(which is harder than it sounds given the baroque Intel architecture). 


I now have a single precision floating point radix 4 butterfly w/o 
twiddles executing in about 0.71 microseconds. That's about 56 
megaflops on average counting only "real" floating point instructions 
(fld, fsto, fadd, fsub). By comparison, "straight" asm code written 
without regard to pipelining takes about 1.3 microseconds. 


When I integrated this into radix-4 DIF C code I'd already written so 
that the asm routine is executed instead of C code in the last stage, 
the overall time for a 256-point complex FFT is 485 microseconds. 

(The pure C code was 525 us). That's better than a million samples/sec. 


The next step is to write a general radix-4 butterfly that can handle 
twiddle factors and arbitrary array stepping so it can be used in 
stages other than the last. This should really get things humping. 


Of course, I'm already about 100x faster than required by a spectrum 
analyzer operating on SSB receiver bandwidths, but it xis* fun to see 
just how fast you can go... 


Phil 


From jalocha@home-gate.ifj.edu.pl Tue Aug 29 08:29:00 1995 

Received: from home-gate.ifj.edu.pl (home-gate.ifj.edu.pl [192.86.14.17]) by 

sysi.tapr.org (8.6.12/8.6.9) with SMTP id IAA15742 for <hfsig@tapr.org>; Tue, 29 

Aug 1995 08:28:48 -0500 

Received: from home.ifj.edu.pl by home-gate.ifj.edu.pl (JNOS1.10h) with SMTP 
id AA3388 ; Tue, 29 Aug 95 16:28:45 UTC 

Date: Tue, 29 Aug 95 15:28:36 MET 

From: "Pawel Jalocha" <jalocha@home.ifj.edu.pl> 

Message-ID: <1036.jalocha@home.ifj.edu.pl> 

To: hfsig@tapr.org 

Reply-to: jalocha@home-gate.ifj.edu.pl 

Subject: Multi-tone, DQPSK modem summary 


Here is a short summary to keep all HFSIG'ers aware of what 
is going on with the multi-tone DQPSK modem. 


The modem has evolved to the following configuration: 
Modulation type: 

There are 15 tones ranging from 750 to 2500 Hz 

spaced by 125 Hz. Each tone is modulated with DQPSK 

(four states => 2 bits/symbol) at 83.33 symbols/second. 

Raw data rate is 2500 bps. 

Peak to RMS ratio (crest factor): 

Not very good... about 4.0 

Frequency error correction: 

The receiver can correct a frequency error of up to +/- 60 Hz. 
There are as well outputs provided for steering the transceiver's 


UP and DOWN buttons for automatic frequency error correction. 
This feature has not been tested yet. 


Forward error correction: 


What is implemented now is basically a block-type FEC with the block size 

of 15 bits. Every bit of a given block is transmitted on a different carrier. 
The intention is that a selective fading/interference would affect least 
amount of bits in a block. 

The bits of one block can be all transmitted at one time or they can be 
spread out in time by an arbitrary factor. 

This feature helps to recover burst errors if at one time all carriers 

get wiped out by a spark or a lighting discharge. 


The FEC schemes are: 
Scheme #0: No FEC, effective data rate is 2500 bps. 


Scheme #41: 11 "real" data bits + 4 CRC bits form a 15-bit block. 
The receiver can correct one flipped bit per 15-bit block 
Effective data rate is 2500*11/15 = 1833.33 bps 


Scheme #3: 5 data bits are mapped into a 15-bit codeword from a set 
of 32 codewords with the hamming distance greater than 7 
between each two selected from the set. These are infact 
Walsh functions. 

The receiver can correct up to three flipped bits per 
15-bit block. 
Effective data data is 2500*5/15 = 833.33 bps 


Hardware platform: 


The code is being developed on a DSPCARD4 by ALEFNUL (credits here 
to Jarkko Vuori and Kaj Vik) but it runs as good on the EVM56002 
from Motorola (thanks to Johan Forrer who ported the DSPCARD4's 
basic system). 


Communication protocol: 


The modem understands KISS, thus it is oriented towards sending frames. 
These can be AX.25 frames but in principle there is no real limit here, 
as KISS can carry any frame. 


Some real on-air tests have been done already by Timo and Joni 

on a short (10-15 km) HF range. AX.25 protocol was used. 

The result... well, the modem works, especially when you use the FEC 
scheme #3. There are certainly troubles and they concentrate around 
the tranceiver's passbands and driving levels. This you can see better 
from Timo's postings :-) 


A modem version exists already which switches the FEC schemes and Interleave 
factors according to KISS commands. However, to my big surprise, I found 
that the packet-radio software I have can not issue an arbitrary 

KISS command ! For example JNOS: 


I say: param tne 12 3 


NOS says: parameter 12 not supported 
I have to ask the JNOS writers to fix this bad feature. 
Future plans ? 


- Double the number of carriers and then I can use the block size 
of 60 bits which is suitable for RS codes with 4-bit symbols. 
The alternative is to add a block-sync sequence and then you can use 
FEC with any block size. 


- Use longer FFT and better window to make the symbols "narrower" in 
frequency. The ones I use now have significant sidelobes. 


It would be certainly helpfull to have more testers, thus anybody 
willing to join please stand up ! You need a shortwave tranceiver, 
a PC, and a DSPCARD4 or an EVM56K. 


Pawel 


From FORRERJ@frl.orst.edu Tue Aug 29 10:39:39 1995 
Received: from amanda.bus.orst.edu (amanda.BUS.ORST.EDU [128.193.10.36]) by 
sysi.tapr.org (8.6.12/8.6.9) with ESMTP id KAA17443 for <hfsig@tapr.org>; Tue, 29 
Aug 1995 10:39:34 -0500 
Received: from frl.orst.edu (FRL.ORST.EDU [128.193.226.10]) by amanda.bus.orst.edu 
(8.6.9/8.6.9) with ESMTP id IAA19003 for <hfsig@tapr.org>; Tue, 29 Aug 1995 
08:39:29 -0700 
Received: from FRL/MERCURY_MAILER by frl.orst.edu (Mercury 1.21); 

29 Aug 95 08:46:07 PST8PDT 
Received: from MERCURY_MAILER by FRL (Mercury 1.21); 29 Aug 95 08:45:52 PST8PDT 
From: "Johan Forrer" <FORRERJ@fr1l.orst.edu> 
Organization: Forest Research Lab. Oregon State 
To: hfsig@tapr.org 


Date: Tue, 29 Aug 1995 08:45:45 PST8PDT 

Subject: Re: [HFSIG:562] Multi-tone, DQPSK modem summary 
Priority: normal 

X-mailer: PMail v3.0 (R1a) 


Message-ID: <BA8FE46747@frl.orst.edu> 
Pawel, 


Thank you very much for the summary of the parallel modem. Congratulations 
is also in order on this fine achievement. What is perhaps not so obvious is 
the complexity of this software - for those that are planning on attending 
the DCC, I hope to devote a bit of time on the modem's software 

and working principles at the DCC. The system will also be on demo to 

give you an opportunity to see it in action and ask questions if you like. 


Congratulations also goes to Joni and Timo for logging the first successful 
tests over the air. I realize that developments are in its infancy and 
there are lots of ideas for improvements. 


To all the contributors to this project, your efforts are 
greatly appreciated - Keep up the good work. 


--Johan, KC7WW 


P.S. Would you mind if we share your summary with others in the next PSR? I 
have a few other items that I will include in the HFSIG summary. 


From FORRERJ@frl.orst.edu Tue Aug 29 10:43:10 1995 
Received: from amanda.bus.orst.edu (amanda.BUS.ORST.EDU [128.193.10.36]) by 
sysi.tapr.org (8.6.12/8.6.9) with ESMTP id KAA17488 for <hfsig@tapr.org>; Tue, 29 
Aug 1995 10:43:02 -0500 
Received: from frl.orst.edu (FRL.ORST.EDU [128.193.226.10]) by amanda.bus.orst.edu 
(8.6.9/8.6.9) with ESMTP id IAA19042 for <hfsig@tapr.org>; Tue, 29 Aug 1995 
08:42:58 -0700 
Received: from FRL/MERCURY_MAILER by frl.orst.edu (Mercury 1.21); 

29 Aug 95 08:49:35 PST8PDT 
Received: from MERCURY_MAILER by FRL (Mercury 1.21); 29 Aug 95 08:49:10 PST8PDT 
From: "Johan Forrer" <FORRERJ@frl.orst.edu> 
Organization: Forest Research Lab. Oregon State 
To: hfsig@tapr.org 


Date: Tue, 29 Aug 1995 08:49:08 PST8PDT 
Subject: Re: [HFSIG:561] FFT progress 
Priority: normal 

X-mailer: PMail v3.0 (R1a) 


Message-ID: <BA9DF76AC4@frl.orst.edu> 
Phil, 


Sounds an exciting devolpment. I would not be surprized at all to see some 
innovative DSP work being done on the faster Intel-based platforms in 
future. You certainly are making good progress towards that. 


--Johan 

From danie.brynard@pixie.co.za Tue Aug 29 23:53:47 1995 

Received: from foxbat.pix.za (foxbat.pix.za [196.11.62.105]) by sys1.tapr.org 
(8.6.12/8.6.9) with ESMTP id XAAQ1251 for <hfsig@tapr.org>; Tue, 29 Aug 1995 
23:53:42 -0500 

Received: from pixie.co.za ([196.11.63.145]) by foxbat.pix.za (8.6.12/8.6.12) with 
SMTP id GAAQ7267 for <hfsig@tapr.org>; Wed, 30 Aug 1995 06:54:14 +0200 

Date: Wed, 30 Aug 1995 06:54:14 +0200 

Message-Id: <199508300454.GAA07267@foxbat.pix.za> 

X-Sender: pakO03226@pixie.co.za (Unverified) 

X-Mailer: Windows Eudora Version 1.4.4 

Mime-Version: 1.0 

Content-Type: text/plain; charset="us-ascii" 

To: hfsig@tapr.org 

From: danie.brynard@pixie.co.za (Danie Brynard) 

Subject: Re: [HFSIG:551] I measured my RX 


>I made the RX test this morning before leaving to the job. I made it in the 
>Same manner as 

>Pawel: I switched the marker generator on and tuned the rig around the 
>marking frequency. 

>If I do not recall wrong, the S meter measures the input _voltage_ so that 
>one S-unit is 6 dB. 


Thanks for the info. What marker generator are you talking about ? In any 
case its a good idea. I will use a crystal based QRP rig I have here with 
good phase noise and measure the receiver passband with. I think my rig can 
step in 1Hz steps hi ! 


73 danie 


From danie.brynard@pixie.co.za Tue Aug 29 23:53:53 1995 

Received: from foxbat.pix.za (foxbat.pix.za [196.11.62.105]) by sys1.tapr.org 
(8.6.12/8.6.9) with ESMTP id XAAQ1263 for <hfsig@tapr.org>; Tue, 29 Aug 1995 
23:53:48 -0500 

Received: from pixie.co.za ([196.11.63.145]) by foxbat.pix.za (8.6.12/8.6.12) with 
SMTP id GAAQ7277 for <hfsig@tapr.org>; Wed, 30 Aug 1995 06:54:21 +0200 

Date: Wed, 30 Aug 1995 06:54:21 +0200 

Message-Id: <199508300454.GAA07277@foxbat.pix.za> 

X-Sender: pakO03226@pixie.co.za (Unverified) 

X-Mailer: Windows Eudora Version 1.4.4 

Mime-Version: 1.0 

Content-Type: text/plain; charset="us-ascii" 

To: hfsig@tapr.org 

From: danie.brynard@pixie.co.za (Danie Brynard) 

Subject: Re: [HFSIG:561] FFT progress 


>Of course, I'm already about 100x faster than required by a spectrum 
>analyzer operating on SSB receiver bandwidths, but it xisx fun to see 
>just how fast you can go... 

> 

Hi Phil 


Your FFT programming for the pentuim etc is very interesting. I have always 
been interested in building my own spectrum analyser. What about have a 
pentuim + radio receiver with say 500kHz baseband bandwidth stepping in 

500kHz steps from 100kHz to 2GHz. This would form a magnificent spectrum 
analyser with unlimited resolution bandwidth ? (sweeps would get slower though) 


For having a span wider than 500kHz one could sweep the radio with its RS232 
port from the PC. I would suggest an AOR-3000A. It does 100kHz - 2.036GHz at 


50Hz increments per second, if I can remember correctly) 


I choose 500kHz ‘cos it is half your current attainable sampling rate of 
about 1MHz, not so ? 


What do you say ? 


73 danie zs6éawk 


From karn@qualcomm.com Wed Aug 30 01:41:15 1995 

Received: from servo.qualcomm.com (servo.qualcomm.com [129.46.128.14]) by 
sysi.tapr.org (8.6.12/8.6.9) with ESMTP id BAAQ3723 for <hfsig@tapr.org>; Wed, 30 
Aug 1995 01:41:12 -0500 

Received: (karn@localhost) by servo.qualcomm.com (8.6.12/QC-BSD-2.5.1) id 
XAAQ5311; Tue, 29 Aug 1995 23:41:10 -0700 

Date: Tue, 29 Aug 1995 23:41:10 -0700 

From: Phil Karn <karn@qualcomm.com> 

Message-Id: <199508300641.XAAQ5311@servo.qualcomm. com> 

To: hfsig@tapr.org 

In-reply-to: <199508300454.GAA07277@foxbat.pix.za> (danie.brynard@pixie.co.za) 
Subject: Re: [HFSIG:566] Re: FFT progress 


>been interested in building my own spectrum analyser. What about have a 
>pentuim + radio receiver with say 500kHz baseband bandwidth stepping in 
>500kHz steps from 100kHz to 2GHz. This would form a magnificent spectrum 
>analyser with unlimited resolution bandwidth ? (sweeps would get slower though) 


Sure! Though I don't know how you'd display 500K points across a 
typical video screen. I.e., although it could run in real time ona 
Pentium, the analyzer would display data much faster than your eyes 
could absorb it. 


Lessee...if you drove a typical high resolution PC display at maximum 
rate, how many samples/sec would that be? Well, a typical display is 
now 1024 pixels across. 


Update that at 72 frames/sec and you have 73728 pixels (frequency 
samples) per sec. Even after scaling my FFT to 1024 points, it would 
still take less than 10% of my Pentium 90. That leaves 90+% percent to 
run the video display driver. 


You can make each of those 1024 horizontal pixels cover whatever 
frequency bin size you like, the FFT computation rate would be the 

same. You could cover a total of 500 Khz across the display if your RF 
and A/D converter bandwidth supports that, but then each bin would 

cover 488 Hz, which might be too coarse for your taste. If you limited 
yourself to a 10.24 KHz span you could get 10 Hz resolution, not counting 
window effects. 


Phil 


From pe@paccomm.com Thu Aug 31 08:01:48 1995 

Received: from paccomm.com ([163.125.30.1]) by sysi.tapr.org (8.6.12/8.6.9) with 
SMTP id IAA22072 for <hfsig@tapr.org>; Thu, 31 Aug 1995 08:01:33 -0500 
X-BBS-Msg-Type: P 

Date: Thu, 31 Aug 95 08:55:20 UTC 

Message-Id: <4823@paccomm.com> 

From: pe@paccomm.com 

To: hfsig@tapr.org 

Subject: Re: [HFSIG:546] Re: Robust modems 


In-Reply-To: your message of Wed, 23 Aug 1995 14:24:49 -0500. 
<4243@paccomm. com> 


You might also try talking to Bath University - they always 
had a very strong HF group, unless the academics have moved 


From karn@qualcomm.com Thu Aug 31 20:33:13 1995 

Received: from servo.qualcomm.com (servo.qualcomm.com [129.46.128.14]) by 
sysi.tapr.org (8.6.12/8.6.9) with ESMTP id UAA01949 for <hfsig@tapr.org>; Thu, 31 
Aug 1995 20:33:10 -0500 

Received: (karn@localhost) by servo.qualcomm.com (8.6.12/QC-BSD-2.5.1) id 
SAA26206; Thu, 31 Aug 1995 18:33:09 -0700 

Date: Thu, 31 Aug 1995 18:33:09 -0700 

From: Phil Karn <karn@qualcomm. com> 

Message-Id: <199509010133 .SAA26206@servo.qualcomm.com> 

To: hfsig@tapr.org 

In-reply-to: <BA9DF76AC4@frl.orst.edu> (FORRERIJ@£r1.orst.edu) 

Subject: Re: [HFSIG:564] Re: FFT progress 


Johan, 


Thanks. I've since gotten the 256-point CFFT time down to 380 us, and 
I think there's xstillx room for improvement. I'm doing the simple 
radix-4 butterfly in 24 adds/subtracts, when I know I can do it in 
only 16 by taking advantage of common subexpressions. ("Simple" 
butterfly means unity twiddles. I have a separate function that does a 
general purpose butterfly with non-unity twiddles that takes a little 
longer.) 


The big problem is in keeping the Pentium's 3-stage floating point 
pipeline full. Floating point add, subtract and multiplies all take 3 
clocks to execute from start to finish, but you can stage 3 operations 
in parallel and retire one instruction per clock if you are careful 
not to stall the pipeline by using the result of an operation as an 
operand to a subsequent instruction that starts less than 3 clocks 
later. This is a fun challenge very much akin to juggling with three 
balls in the air at once... 


Phil 


From danie.brynard@pixie.co.za Thu Aug 31 23:42:41 1995 

Received: from foxbat.pix.za (foxbat.pix.za [196.11.62.105]) by sys1.tapr.org 
(8.6.12/8.6.9) with ESMTP id XAA04324 for <hfsig@tapr.org>; Thu, 31 Aug 1995 
23:42:35 -0500 

Received: from pixie.co.za ([196.11.63.140]) by foxbat.pix.za (8.6.12/8.6.12) with 
SMTP id GAA10424 for <hfsig@tapr.org>; Fri, 1 Sep 1995 06:43:12 +0200 

Date: Fri, 1 Sep 1995 06:43:12 +0200 

Message-Id: <199509010443.GAA10424@foxbat.pix.za> 

X-Sender: pakO03226@pixie.co.za (Unverified) 

X-Mailer: Windows Eudora Version 1.4.4 

Mime-Version: 1.0 


Content-Type: text/plain; charset="us-ascii" 

To: hfsig@tapr.org 

From: danie.brynard@pixie.co.za (Danie Brynard) 

Subject: Re: [HFSIG:562] Multi-tone, DQPSK modem summary 


>Here is a short summary to keep all HFSIG'ers aware of what 
>is going on with the multi-tone DQPSK modem. 
> 


>It would be certainly helpfull to have more testers, thus anybody 
>willing to join please stand up ! You need a shortwave tranceiver, 
>a PC, and a DSPCARD4 or an EVM56K. 

> 

Hi Pawel 


Thanks for this. I am slowly cathing up. I am currently not able to tx from 
NOS using NEWQPSK.ASM 


danie 


From danie.brynard@pixie.co.za Thu Aug 31 23:43:01 1995 

Received: from foxbat.pix.za (foxbat.pix.za [196.11.62.105]) by sys1.tapr.org 
(8.6.12/8.6.9) with ESMTP id XAAQ4337 for <hfsig@tapr.org>; Thu, 31 Aug 1995 
23:42:51 -0500 

Received: from pixie.co.za ([196.11.63.140]) by foxbat.pix.za (8.6.12/8.6.12) with 
SMTP id GAA10457 for <hfsig@tapr.org>; Fri, 1 Sep 1995 06:43:28 +0200 

Date: Fri, 1 Sep 1995 06:43:28 +0200 

Message-Id: <199509010443 .GAA10457@foxbat.pix.za> 

X-Sender: pakO03226@pixie.co.za (Unverified) 

X-Mailer: Windows Eudora Version 1.4.4 

Mime-Version: 1.0 

Content-Type: text/plain; charset="us-ascii" 

To: hfsig@tapr.org 

From: danie.brynard@pixie.co.za (Danie Brynard) 

Subject: Re: [HFSIG:567] Re: FFT progress 


Thanks Phil for the Spectrum analyser thoughts. Another solution to a 
personal spectrum analyser for a radio ham would be using a AOR AR-3000A 
(100kc-2GHzZ) scanner + PC with s/w or the new Trident 1MHz to 1GHz scanner 
which even supports a analog X-Y signal out to an oscilloscope. PC's are 
nasty things in a RF lab. They make a hell of a lot of noise... Anybody 
who's doing that ? 


73 danie zs6éawk 


